How was Training?

more

“It was fantastic course - very insigthful and valuable. Thank you.” - Architect, Freshfields, UK, Sep 2013

Recommend PEAF?

more

“Yes - easy to be understood” - IT Head, CAS, Indonesia, Feb 2015












Most people think of principles in terms of Business, Data, Application and Technology – or some other similar categorisation. Pragmatic considers principles from a more pragmatic perspective.

It is recognised that there is a more complex mapping between principles and their categorisations (rather than the usual simplistic one-to-one mapping), which is one thing that makes principles so powerful. One might say that the best principles are ones that apply to more than one part of the Enterprise and/or more than one area.

Principles can (and should be) be associated with one or more parts of the Enterprise.

For example, some Principles apply only to Transformation like “Increase Technology Independence”. Some principles apply to all parts of the Enterprise such as “Explain Decisions”

In addition, we can also classify Principles in terms of applying to Methods, Artefacts, Culture or Environment.

Here we define a set of Best Practice principles that apply to most Enterprises and how each principle maps to DOTS and MACE.

[DOTS : MACE]

Apply Principles Universally

We apply principles to all parts of the Enterprise.

Rationale:

¨      If parts of the Enterprise are exempt from these principles, this will undermine and reduce the benefits gained to an unacceptable level.

Implications:

¨      Parts of the Enterprise may react negatively and resist the removal of the “flexibility” to pick and choose which principles to adopt.

¨      All change initiatives will be reviewed for their compliance with the principles.

¨      An unresolved conflict with a principle will be resolved by issuing a Waiver which will then be analysed, costed and managed.

Metrics:

¨      Raw: % of Initiatives that have been examined for compliance with the principles.

¨      Raw: Per project: Number of waivers issued

¨      Raw: Per project: Number of waiver issues

¨      Raw: Per project: Total Cost of waiver issues

¨      Raw: Per project: Number of waiver risks

¨      Raw: Per project: Total impact cost of waiver risks

¨      Raw: Per project: Number Waivers avoided

¨      Derived: Total: Number of live waivers

¨      Derived: Total: Number of waivers issued

¨      Derived: Total: Number of waivers closed

¨      Derived: Total: Number of waiver issues

¨      Derived: Total: Total Cost of waiver issues

¨      Derived: Total: Number of waiver risks

¨      Derived: Total: Total impact cost of waiver risks

¨      Derived: Total: Number Waivers avoided (At which level)

 

Enterprise Compliance

The Enterprise must comply with all relevant laws, policies and regulations.

Rationale:

¨      The Enterprise is not viable unless it complies with appropriate laws and regulations.

Implications:

¨      A programme of training is required to make appropriate people aware of appropriate laws, policies and regulation and when, where and how to apply them.

¨      Non Functional Requirements need to identify the laws, polices and regulations (internal and external) that solutions must comply with.

Metrics:

¨      Raw: % of systems which have been formerly reviewed and deemed compliant.

Enterprise Continuity

We maintain appropriate levels of Enterprise Continuity.

Rationale:

¨      The impact to the Enterprise if it is unable to conduct its business is not only measured in terms of lost revenue and wasted employee time, but can also have an impact on the Enterprise’s reputation with its suppliers and its customers.

¨      The impact of any disruption can continue long after the actual disruption has been corrected.

Implications:

¨      The component parts of the Enterprise and the Methods, Artefacts, Culture and Environment they use must be assessed in terms of the importance and criticality to the business.

¨      The level of business continuity to be put in place is dependent upon the importance or criticality to the business.

¨      The Business continuity plan and measures put in place will be adequately tested periodically.

¨      The Business continuity plan will be reviewed periodically.

¨      Appropriate levels of availability, disaster recovery, and security for all systems (not just IT systems) will be addressed in their design.

Metrics:

¨      Raw: Existence of a BC Risk Log.

¨      Raw: Number of open risks.

¨      Raw: % of risks with mitigation tasks.

¨      Raw: % of mitigation tasks planned for action.

¨      Raw: % of mitigation tasks in progress.

¨      Raw: % of mitigation tasks completed.

¨      Raw: Existence of a BC test plan.

¨      Raw: Execution of the BC test plan every 12 months

¨      Raw: % of applications that have been assigned a business criticality.

¨      Raw: % of applications that meet the level of business criticality assigned.

[DOTS : MACE : Data]

Structured Modelling

We hold information in structured rather than unstructured forms.

Rationale:

¨      If information is held in unstructured forms, there is a great risk that it cannot be reused, related to information it depends on or related to information that depends on it.

¨      Reducing the ability to relate information and see a clear line of sight between it, greatly increases the risk of making bad decisions.

¨      If information is held in unstructured forms, there is a great risk that any problems it contains will not be seen and corrected until much later.

¨      Seeing problems much later than when problems are introduced greatly increases the risk of wasting resources and the risk of not achieving what was planned.

Implications:

¨      Appropriate Tools and Processes will be required.

¨      It can take longer to create and work with information in structured forms.

¨      Increase time and resources will likely be required.

Metrics:

¨      Raw: Amount of information in use, stored in unstructured forms.

¨      Raw: Amount of information in use, stored in structured forms.

¨      Derived: % of unstructured vs structured information in use.

[DOTS : M]

Plan Ahead and Organise

We do work in a Strategic way because we do the necessary planning to allow us to.

Rationale:

¨      Most companies tend to find themselves in a fire fighting spiral, where problems and priorities are focussed on just keeping the Business running.

¨      This is a spiral because work that should be done to head off the next potential problem or panic is not done resulting in the potential problem becoming a real problem to such an extent that it makes it onto the panic sheet.

¨      If you do not plan to do any strategic work, you will never do any strategic work.

Implications:

¨      The firefighting spiral needs to be broken and the only way to do that is to plan ahead and organise work not only based on short term objectives but also from the point of view or stopping things becoming a crisis in the future.

¨      Therefore a proportion of budget and effort needs to be directed towards preventing things becoming a crisis in the future rather than exclusively performing crisis management and firefighting activities.

¨      Only by planning ahead will the crisis management spiral be broken.

Metrics:

¨      Raw: % of budget spent on strategic work.

Reduce Manual Processes

We reduce and remove manual processes - but only when there is a clear business reason for doing so.

Rationale:

¨      The benefit of manual processes are that they are immeasurably flexible, can be easily changed (on a daily basis if necessary) with little cost and without any of the problems associated with changing electronic software systems. This is the reason, manual processes tend to grow and grow through an Enterprise. However, manual processes require people to operate them, office space, desks, HR, or not scalable, etc, etc Therefore straight through processing (STP) is a valid target aim.

¨      There are places where manual processes should and/or must be used as systems and technology cannot currently replace them or they are more cost effective.

¨      Cost is only one aspect though, people are good at non-repetitive highly complex tasks rather than repetitive simple tasks and so it makes sense to use one of the most important assets of the company (i.e. its people) in the best way possible.

Implications:

¨      People rarely ask the question “why do you do it that way”. Even if they do, the usual answer is “because that’s the way we’ve always done it”. It takes a determined and concentrated effort to research, investigate and identify processes that can be reduced or removed.

¨      People can believe that removing or reducing manual processes will make them less worthwhile to the company, give them less job satisfaction and/or could ultimately lead to loss of jobs. This is a misnomer in that what usually happens is that people feel more worthwhile and get better job satisfaction and job losses do not materialise as people are freed up to do more productive and less repetitive work.

¨      Usually the people best suited to spot where improvements could be made are the people on the coal face who have to follow and work within these processes on a day to day basis.

Metrics:

¨      Raw: The number of manual, semi-automatic and automatic process.

¨      Raw: The cost of manual, semi-automatic and automatic process.

¨      Derived: The total cost of manual, semi-automatic and automatic process.

¨      Derived: The ratio of the number of manual to semi-automatic to automatic processes.

¨      Derived: The ratio of the cost of manual to semi-automatic to automatic processes.

[DOTS : A]

Artefacts Must Be Complete, Sufficient and Comprehensible

We ensure that all artefacts used are of the quantity, quality and format required by the person using the artefact.

Rationale:

¨      Artefacts are used by one process to perform an action.

¨      Artefacts used by a process that are not of the required quantity, quality and format, greatly increases the risk of that process producing bad outputs.

¨      If those artefacts are decisions, bad decisions can end up being piled upon bad decisions.

Implications:

¨      Whether an artefact is Complete, Sufficient and Comprehensible is determined by the person who will use the artefact not by the person that produces the artefact.

Metrics:

¨      Raw: Number of artefacts labelled “satisfactory” by those that use them.

¨      Raw: Number of artefacts labelled “unsatisfactory” by those that use them.

¨      Derived: % of “satisfactory” artefacts.

[DOTS : A : Data]

Treat Data as Assets

We accept that Data are assets that have value to the Enterprise.

Rationale:

¨      Data is the blood of most Enterprises, and its value can be huge.

¨      Data, like anything else of value, needs to be maintained if its use is to be preserved.

¨      Collecting and storing data can be very time consuming and resource intensive, and so to not maintain data (so it can be used in the future) is extremely inefficient.

¨      Data exists in two fundamental categories:

¨      Production: These data are the product (for a data based Enterprise - like a bank). They are the crown jewels of the Enterprise.

¨      Business: These data aids decision-making. Unless this data is accurate, current and available when it is needed bad decisions can be made with far reaching consequences to the entire Enterprise.

Implications:

¨      Each major data entity will have an associated data steward assigned responsible for managing the data.

¨      Data Stewards are responsible for the quality of the data they are responsible for.

¨      Procedures must be created to monitor data quality and correct any errors. A set of Data Management Policies are required.

¨      A Metadata repository is required.

¨      Common tools are required for creating, maintaining and managing data.

Metrics:

¨      Raw: Does a Business Data Model exist?

¨      Raw: % that have an assigned business data steward.

¨      Raw: % that have defined data quality procedures.

¨      Raw: Per Entity: Data Quality score.

¨      Derived: Total Data Quality score.

Do Not Duplicate Data

We ensure that Data are shared across organisational and technical boundaries.

Rationale:

¨      The Enterprise holds a large amount of data, but it is stored in multiple physical databases.

¨      Duplication of data costs money in effort to maintain it and to synchronise its copies.

¨      Duplication means there are many versions of “the truth” making decision making very haphazard.

¨      Duplication adds un-needed complexity.

Implications:

¨      Data Sharing and Data Security can be contradictory - It is important to recognise that data stored in the same place can have different security requirements.

¨      A set of Data Management Policies are required.

¨      A Metadata repository is required.

¨      Common tools are required for creating, maintaining and managing data.

Metrics:

¨      Raw: Do Data Management Polices and Standards exist?

¨      Metrics for measuring the adherence and effectiveness of these are defined in the associated policies/standards.

Make Data Accessible

We ensure that people have access to the data required to perform their duties.

Rationale:

¨      Data which is accessible increases efficiency and effective decision making.

¨      Access to data must be considered for an Enterprise wide perspective otherwise data silos are likely to grow.

Implications:

¨      Different levels of access need to be defined for all data entities - Create, Read, Update, Delete.

¨      An Enterprise wide access framework is required to manage access based on Enterprise role rather than individual persons.

¨      A set of Data Management Policies are required.

¨      A Metadata repository is required.

¨      Common tools are required for creating, maintaining and managing data.

Metrics:

¨      Raw: A Data Accessibility user survey has been created.

¨      Raw: % of entities that have had a Data Accessibility user survey carried out.

¨      Raw: % Data Accessibility score for each entity.

¨      Derived: Total % Data Accessibility.

Define Data

We define and use Data consistently.

Rationale:

¨      For the Enterprise to come together and work in a partnership there must be a common and well understood definition for all the important data entities within the Enterprise.

Implications:

¨      A Metadata repository is required.

¨      Whenever there is disagreement over the use of an existing definition or when new definitions are required the Architecture Review Board will ensure consistency and completeness.

Metrics:

¨      Raw: % complete Business Data Dictionary.

Secure Data

We protect Data from unauthorized use and disclosure.

Rationale:

¨      In the same way access to applications is controlled through role based security, so must access to data.

¨      It is all too easy to have an application provide elaborate security access control and restrictions but if the data that the application uses can be accessed directly in a relatively easy fashion then that data is not sufficiently protected.

¨      This is especially pertinent to integrations across Enterprise boundaries where different data in a data set may be considered differently in terms of security.

Implications:

¨      It is possible that to gain data security, data is physically separated into different database. This may not be the optimal method of securing the data since it needlessly fragments the data and can cause maintenance issues.

¨      A Data security policy and standards are required.

¨      Existing data sources will need assessing and evaluating.

¨      Like applications, security must be designed into data entities and attributes at design time, not by adding it later.

Metrics:

¨      Raw: % of Databases that have had a security assessment.

¨      Raw: Do Best Practice Data Security Policies and Standards exist?

¨      Metrics for measuring the adherence and effectiveness of these are defined in the associated policies/standards.

[DOTS : C]

Explain Decisions

We ensure that “…because I said so” will never be used as the reason or rationale for any decision.

Rationale:

¨      Allowing “because I said so” as a reason for decisions is deeply damaging to the Enterprise as a whole and to individuals. Allowing it shows people that there is no point in asking “why”.

¨      It promotes a good culture to make sure people understand why decisions are been taken.

¨      This does not mean that all people will be happy with all decisions.

¨      If people understand the reason for a decision, they will accept the decision more readily even if they do not agree with it.

Implications:

¨      It takes time and energy to explain reasons to people.

¨      Some people may not like this principle if they have in the past been used to saying “Because I said so”.

¨      This does not imply that every decision will be explained to every person. What it means is that if someone has reason to ask why a decision is being made then that decision will be explained.

Metrics:

¨      Raw: The number of times “Because I said so” is used.

Record Decisions

We ensure that people understand why decisions are made and that the reasons for those decisions are recorded.

Rationale:

¨      “You can please some of the people all of the time, you can please all of the people some of the time, but you can't please all of the people all of the time.” - John Lydgate.

¨      A lot of “non-acceptance” of decisions stems from people not understanding why a decision was made.

¨      If decisions are explained, a lot of peoples “problems” with those decisions are likely to vanish.

¨      Explaining why decisions are made helps people accept them, and make them work.

¨      Even if people still do not like a decision, if they can see the rationale behind a decision, they are much more likely to “run with it”.

Implications:

¨      It is the responsibility of the person making a decision to explain that decision to those who are affected by it.

¨      Requires time and resources.

¨      People need an environment that allows then to feel comfortable and to have the mandate to ask for decisions to be explained.

¨      Management needs to create that environment.

Metrics:

¨      Raw: Number of decisions taken.

¨      Raw: Number of decisions documented.

¨      Derived: % of documented decisions.

Consider Context & Implications

We ensure that all decisions are based on understanding the context that causes them to be made and the implications that making them create.

Rationale:

¨      Decisions made without first seeing and then understanding the full context, greatly increases the risk of making bad decisions.

¨      Decisions made without first seeing and then understanding the full implications, greatly increases the risk of making bad decisions.

Implications:

¨      The Context for Decisions must be documented.

¨      The Implications for Decisions must be documented.

¨      Appropriate Tools and Processes will be required.

¨      Increased time and resources will likely be required.

Metrics:

¨      Raw: Number of decisions made that did not consider the full context and/or implications.

Work Smart not Hard

We concentrate on expending the 20% of the effort that provides 80% of the benefit.

Rationale:

¨      "The Pareto principle", "The law of the vital few" or "The principle of factor sparsity" state that, for many events, roughly 80% of the effects come from 20% of the effort.

¨      If we concentrate on addressing the 20% that provide us with 80% of the benefits we will be as effective as we can reasonably be, whilst still allowing for further improvement.

Implications:

¨      Requires time and resources.

¨      People need an environment that allows then to feel comfortable and to have the mandate to think-out-of-the-box.

¨      Management needs to create that environment.

Metrics:

¨      Raw: Number of instances where the 8020 rule is applied.

Consider Efficiency

We consider how things are done, rather than only what things are done.

Rationale:

¨      The Enterprise will always have finite resources.

¨      Those resources are precious, and the return on their use must be maximised.

¨      What the Enterprise does, is not so much of a differentiator as how it does, what it does.

¨      Efficiency is a key to strategic success.

Implications:

¨      Requires time and resources.

¨      People need an environment that allows then to feel comfortable and to have the mandate to consider efficiency.

¨      Management needs to create that environment.

Metrics:

¨      Raw: Amount of resources spent on efficiency.

Consider Important Non-Urgent Work

We break the negative feedback loop of always spending more time on Important Urgent Work (Firefighting) to the detriment of Important Non-Urgent Work.

Rationale:

¨      Increasing time spent on Important Non-Urgent work, tends to reduce the amount of time subsequently required to deal with Important Urgent work (Firefighting).

¨      Reducing the amount of time dealing with Important Urgent work (Firefighting), tends to increase the amount of time available for Important Non-Urgent Work.

¨      Prevention is better than cure.

Implications:

¨      Requires time and resources.

¨      People need an environment that allows then to feel comfortable and to have the mandate to consider Important Non-Urgent work.

¨      Management needs to create that environment.

Metrics:

¨      Raw: Amount of resources spent on efficiency.

Consider Things of Fundamental Importance

We spend more time thinking more deeply about fundamental things and getting those things correct.

Rationale:

¨      Concentrating on things of Fundamental Importance are likely to yield better decisions and better outcomes than ignoring them or not giving them enough consideration.

¨      If you do not get fundamentals right, it is likely to cause serious problems further down the line.

Implications:

¨      Can be subjective.

¨      Requires time and resources.

¨      People need an environment that allows then to feel comfortable and to have the mandate to Consider Things of Fundamental Importance.

¨      Management needs to create that environment.

Metrics:

¨      Raw: Amount of resources spent on Considering Things of Fundamental Importance.

Consider the True Value of Things

We look deeper into things to see where true value lies rather than only looking at things with obvious value.

Rationale:

¨      .

Implications:

¨      Requires time and resources.

¨      People need an environment that allows then to feel comfortable and to have the mandate to Consider the True Value of Things.

¨      Management needs to create that environment.

Metrics:

¨      Raw: Amount of resources spent on Considering the True Value of Things.

Prioritize Substance over Style

We value the content and substance of ideas and argument over and above the way those ideas or arguments are communicated.

Rationale:

¨      The way something is said or a message is delivered can unduly influence those listening to and affected by it.

¨      The Halo Effect can mean that a decision with dubious value could be accepted.

¨      The Horns Effect can mean that a decision with great value could be rejected.

¨      “If the honourable gentlemen would pay more attention to what I am saying, rather than how I am saying it, he might receive a valuable education in spite of himself” - Margaret Thatcher.

Implications:

¨      People need to feel comfortable expressing their opinions even though they may not be delivered in a “professional” manner.

¨      People need to focus on the content of opinions rather that their delivery.

¨      Management needs to create that environment.

Metrics:

¨      Raw: The number of times substance is wins out over style.

Consider Future Benefit

We consider things from the point of view of future benefit rather than only in terms of short term benefit.

Rationale:

¨      Short term benefits satisfy the craving for low hanging fruit and immediate gratification, however, not balancing immediate needs for more longer term needs will usually cause longer terms problems that can easily outweigh short term gains..

Implications:

¨      Requires time and resources.

¨      People need an environment that allows then to feel comfortable and to have the mandate to Consider Future Benefit.

¨      Management needs to create that environment.

Metrics:

¨      Raw: Amount of resources spent on Considering Future Benefit.

Expose Individual and Contrary Opinion

We seek out and hear people with opinions that are contrary to the opinions of people that have more “seniority” or contrary to the opinions of the majority.

Rationale:

¨      Being senior does not mean that someone is right.

¨      Being in the majority does not mean that someone is right.

¨      Innovation and progress can come from seeing things that others cannot.

¨      If we do not allow (demand) contrary opinion, the risks of making bad decisions are greatly increased.

Implications:

¨      People in power may feel very uncomfortable allowing contrary opinions to be heard.

¨      People understanding that being in the majority does not automatically mean they are right.

¨      People need to feel comfortable and able to express contrary opinions.

¨      Management needs to create that environment.

Metrics:

¨      Raw: The number of contrary opinions heard.

Change Actions and Beliefs over Perceptions

Don't Allow Cognitive Dissonance to Corrupt Decisions.

Rationale:

¨      Cognitive dissonance theory is based on three fundamental assumptions:

¨      Humans are sensitive to inconsistencies between actions and beliefs.

¨      Recognition of this inconsistency will cause dissonance, and will motivate an individual to resolve the dissonance.

¨      Dissonance will be resolved in one of three basic ways:

§  Changing ones Belief.

§  Changing ones Actions.

§  Changing ones Perception.

¨      It is inherently very hard for people to change their Beliefs - otherwise they would not be Beliefs.

¨      It can be very difficult for people to change their Actions (one type of action is a decision)

¨      It is very easy for people to change their Perceptions to justify a Belief or an Action regardless of how erroneous the Belief or Action may be.

Implications:

¨      People will feel very uncomfortable changing their Beliefs or Actions.

¨      People need to fee that changing their Beliefs or Actions is seen as a positive rather than a negative.

¨      An environment will be required that stop people feeling uncomfortable.

¨      Management needs to create that environment.

Metrics:

¨      Raw: The Number of Beliefs that have changed.

¨      Raw: The Number of Actions that have changed.

Don't Jump to Conclusions

Just because something seems to be obvious doesn’t necessary mean that it is.

Rationale:

¨      A general (insatiable) appetite for quick wins and doing things faster can cause people to make snap decisions.

¨      Decisions that are taken without the required information to make them are not decisions, but arbitrary guesses.

Implications:

¨      "Analysis Paralysis" is a phrase often used when people who want to jump to conclusions or to repress others who may be more wary.

¨      Requires time and resources.

¨      People need an environment that allows then to feel comfortable spending the time required to make well founded decisions.

¨      An environment will be required that stop people feeling uncomfortable.

¨      Management needs to create that environment.

Metrics:

¨      Raw: The number of decisions that were going to be made incorrectly, but were changed.

Think Strategically

Decisions should be made to provide maximum benefit to the Enterprise as a whole.

Rationale:

¨      Decisions that are made purely from a tactical perspective provide less long term value than those made for the benefit of the Enterprise as a whole.

¨      All parts of the Enterprise only exist to enable and fulfil the goals and objectives of the Enterprise.

Implications:

¨      Some short term goals may need to be sacrificed in preference to larger and more strategic goals.

¨      Some projects may need extra funding to achieve this.

¨      IT systems and services will be evaluated in terms of the benefits to the whole Enterprise rather than to satisfy the needs of a particular project or group.

Metrics:

¨      Raw: Number of decisions which produce a multi project, multi department benefit as opposed to a singular benefit.

¨      Raw: The number of Applications shared across boundaries.

¨      Raw: The number of Services shared across boundaries.

¨      Raw: The number of Components shared across boundaries.

No Bullying

Actions and Decisions are based on rational thinking not on power, control or position.

Rationale:

¨      Bullying can take many forms, not just physical.

¨      Bullying: Anyone who holds some kind of power, control or position over someone else, and who uses that power, control or position to force another person to do (or not to do) something.

¨      Bullying only serves to benefit the individual and damage the Enterprise.

Implications:

¨      People who are used to using bullying as a tool to get things done will feel very uncomfortable not being able to.

¨      People who are used to being bullied will feel very uncomfortable exposing it when it happens.

¨      An environment will be required that stop people feeling uncomfortable.

¨      Management needs to create that environment.

Metrics:

¨      Raw: Number of Incidences of Bullying.

Expose Problems

Problems need to be exposed, evaluated and dealt with when they occur, not tripped over later when correcting them will be more difficult and possibly impossible.

Rationale:

¨      Solving problems as early as possible greatly limits the damage and knock on problems those problems can cause later.

¨      Hiding “bad news” only serves to benefit the individual and damages the Enterprise.

¨      Sometimes information can come to light that requires a very large change in what is being done.

¨      The bigger the problem, the more likely it is for people want to gloss over it and ignore it.

¨      Either because they feel they may be looked on as having done something wrong, or because the implications of accepting it will cause an increase or loss of a large amount of time, money, effort, etc.

¨      However inconvenient and painful the truth is, it is usually an order of magnitude less that the pain that will be suffered later if it is not dealt with.

Implications:

¨      People who are used to hiding problems will feel very uncomfortable not being able to.

¨      People who are used to seeing problems hidden will feel very uncomfortable exposing them.

¨      An environment will be required that stop people feeling uncomfortable.

¨      Management needs to create that environment.

Metrics:

¨      Raw: Number of problems exposed.

¨      Raw: Number of problems hidden.

¨      Derived: Ratio of problems exposed vs hidden.

[DOTS : E : IT]

Ease-of-Use

Applications should be easy to use. The underlying technology is transparent to users, so they can concentrate on tasks at hand.

Rationale:

¨      The more a user has to understand the underlying technology, the less productive that user is.

¨      Ease-of-use is a positive incentive for use of applications. It encourages users to work within the integrated information environment instead of developing isolated systems to accomplish the task outside of the Enterprise’s integrated information environment.

¨      Most of the knowledge required to operate one system will be similar to others therefore training is kept to a minimum, and the risk of using a system improperly is reduced.

¨      Using different applications should be as intuitive as driving different cars.

Implications:

¨      Applications will be required to have a common "look and feel" and support ergonomic requirements. Hence, the common look and feel standard must be designed and usability test criteria must be developed.

¨      Guidelines for user interfaces should not be constrained by narrow assumptions about user location, language, systems training, or physical capability. Factors such as linguistics, customer physical infirmities (visual acuity, ability to use keyboard/mouse), and proficiency in the use of technology have broad ramifications in determining the ease-of-use of an application.

¨      It is accepted that increased use of COTS applications may mean this principle is not met as much as would be if purely bespoke applications are used.

Metrics:

¨      Raw: An Ease-Of-Use satisfaction survey has been created.

¨      Raw: % of services/applications that have had an Ease-Of-Use satisfaction survey carried out.

¨      Raw % Ease-Of-Use satisfaction score for each service/application.

¨      Derived: Total % Ease-Of-Use satisfaction.

Common Use

Applications that can support and/or be reused by multiple parts of the Enterprise are favoured over those that are only point solutions.

Rationale:

¨      Applications that only solve one problem or support one part of the Enterprise exacerbate the proliferation of applications and their associated technologies that cause increased cost and complexity.

Implications:

¨      Existing point solutions may need to be replaced.

¨      Careful management of projects is required to identify possible synergies as early as possible.

¨      Projects may need extra investment to allow their scope to be expanded in order to procure a broader application or service.

Metrics:

¨      Raw: Number of applications providing essentially the same functionality or services

Security

Applications and Services will be secured from unauthorized access.

Rationale:

¨      Malicious intrusion, viruses, and terrorism increasingly threaten the Enterprise’s systems.

¨      The Enterprise has a duty to maintain its customer’s and supplier’s trust in its systems from unauthorized access and to preserve confidentiality where required.

¨      Secure systems ensure the continuity of the Enterprise’s business.

Implications:

¨      Systems must be secured with application security best practices.

¨      Application security assessments being conducted on a regular basis.

¨      Must identify, publish, and keep applicable policies current.

¨      Security must enable not impede business.

¨      Security must be designed into the Enterprise, its structure, processes and systems from the beginning. Adding it later seriously compromises quality and/or seriously increases costs.

Metrics:

¨      Raw: % of Systems, Applications, Departments that have had a security assessment.

¨      Raw: Do Best Practice Application Security Policies and Standards exist?

¨      Metrics for measuring the adherence and effectiveness of these are defined in the associated policies/standards.

 

[T : M]

Manage Enterprise Debt™ Value (EDV)

Enterprise Debt™ will be exposed, documented and managed.

Rationale:

¨      Enterprise Debt™ exists. It is created every day. This principle recognises its existence and therefore the requirement to expose and manage it.

¨      Enterprise Debt™ incurs interest. This interest is paid as long as the interim change (debt) exists in the form of maintenance and other costs that would not exist otherwise. Remedial change is like paying off a (portion of a) loan and as such reduces overall debt and subsequent interest.

¨      Enterprise Debt™ is not inherently a bad thing. It is an important tool for an Enterprise to achieve its goals and objectives. Like financial debt, Enterprise Debt™ needs to be visible & managed. If Debt is not managed it will inevitably only increase.

¨      Like any debt, Enterprise Debt™ is bad when you:

¨      Don’t know you are incurring it.

¨      Don’t know how you will pay off the debt.

¨      Don’t know the interest rate.

¨      Don’t know how long you will have to pay interest for.

Implications:

¨      Changes are required in process and culture to enable identification of Enterprise Debt™ to be an acceptable and appropriate thing to do.

¨      A Strategic Investment Board (with budget) is required to sit above all projects and programs.

Metrics:

¨      Raw: The Enterprise Debt™ (cost of the issues and risks created) of each programme, project and initiative.

¨      Derived: The total cost of Enterprise Debt™.

Manage Enterprise Debt™ Ratio (EDR)

All change must be classified in terms of the Enterprise Debt™ Ratio (Strategic vs Tactical vs Remedial)

Rationale:

¨      Strategic: Changes that take you directly from where you are to where you want to be. (May or may not also satisfy a short term need.)

¨      Tactical: Changes that satisfy a short term need, but does not take you from where you are to where you want to be in the most effective and/or efficient way.

¨      Remedial: Changes that correct previous Tactical change. This remedial change will also consist of Strategic and Tactical change.

¨      All projects have a Business and a Technical change component. The Enterprise Debt Ratio™ for each can be very different. E.g. The Business change component of an initiative may be 90:10:0, whereas the IT change component of the same initiative may be 10:30:60.

¨      Strategic changes do not increase Enterprise Debt™ but could reduce it as a side effect.

¨      Tactical changes, by definition, increase Enterprise Debt™.

¨      Remedial changes decreases Enterprise Debt™.

¨      When budgets and timescales are constrained, the bias is more likely to be towards Interim change (taking on more debt) whereas when budgets and timescales are more relaxed the bias is more likely to be towards Strategic and Remedial change (paying off the debt).

Implications:

¨      All Programmes, Projects and Initiatives need to be classified in terms of Strategic vs Interim vs Remedial ratios, for the Business change component and for the IT change component.

¨      It should be also noted that the Enterprise Debt Ratio™ is a ratio of how change is effected not why. E.g. Change may be driven by a strategic imperative but if the way that change is effected is interim then the Debt Ratio would be 0:100:0 and not 100:0:0

Metrics:

¨      Raw: The % of programmes, projects and initiatives that have the Enterprise Debt Ratio™ identified.

¨      Derived: The total %’s of Strategic vs Interim vs Remedial ratios (Business & IT)

Be Architecture Centric

Adopt Architecture Best Practice

Rationale:

¨      Architecture is about structure, reuse, cost reduction and flexibility.

¨      An architecture centric approach to delivering services to the Business is a widely accepted and adopted best practice for success.

¨      Currently there are limited architecture resources, groups, documentation, principles, policies, standards, governance.

¨      Work undertaken tends to be tactical rather than strategic in focus.

¨      IT systems are diverging in terms of technology and applications and point solutions are proliferating. IT finds it difficult to provide a good service to the Business. This results in IT being viewed as a cost rather than a positive value. IT has a tactical reactive focus rather than a proactive strategic focus.

¨      This will allow the Enterprise to be in control of its IT capabilities and fully understand how they are related to each other and the Business.

¨      Projects produce good quality, fit for purpose solutions.

Implications:

¨      Define an architecture framework.

¨      Introduce/improve and integrate Enterprise, Solution and Technical architecture processes and products.

¨      Introduce a Best Practice project management approach.

¨      Introduce Business/IT planning and Project Portfolio Management.

Metrics:

¨      Utilise the Metrics (part of the Maturity Model) defined in the Adoption section of the Framework you have adopted.

Be Service Oriented

Adopt a service based approach instead of an application based approach.

Rationale:

¨      The traditional application based approach to providing functionality does not promote reuse and flexibility at the Business level. i.e it is difficult to rearrange and re-connect applications as business needs change.

¨      Adopting a Service based approach to providing services to the Business will increase Business agility enabling it to respond faster and more efficiently to internal and external change .

Implications:

¨      We need to identify and provide reusable business level services that can be linked together and easily changed to increase business agility.

¨      A Service based approach is not a product that can be bought and installed. It is more a way of thinking and structuring things. This can be difficult to grasp although the benefits can be substantial.

¨      Vendors of packaged applications (COTS) may not be as mature as the Enterprise would like and may require work to define and wrap various functionality as services.

Metrics:

¨      Raw: Number of internal facing Functional Services defined.

¨      Raw: Number of external facing Functional Services defined.

¨      Raw: Number of internal facing Data Services defined.

¨      Raw: Number of external facing Data Services defined.

¨      Raw: % of programmes, projects and initiatives which are defining new services.

¨      Raw: % of programmes, projects and initiatives which are using existing services.

Consolidate

Consolidation is considered at all times and there is proactive drive towards reducing proliferation and complexity.

Rationale:

¨      Anything which is complex costs more to produce and maintain.

¨      This increase in cost tends to increase in an exponential manner - initially not having much impact on costs and timescales, but as complexity grows there comes a point whereby costs become prohibitive.

¨      Consolidation is concerned across the board e.g. Processes, Applications, Vendors, Hardware, Software, Services.

Implications:

¨      Consolidation is not something that happens overnight and usually consolidation projects do not make economic sense.

¨      Consolidation should become part of all projects remits and the Business should provide the resources to effect consolidation as opportunities arise.

¨      Consolidation should become part of the Strategising and Roadmapping phases, allowing for pieces of consolidation work to be included in the project portfolio.

Metrics:

¨      Raw: % of programmes, projects and initiatives that include a consolidation component.

 

Refactor Where Possible

Whenever anything is changed, we should always look to see if we can improve it at the same time.

Rationale:

¨      Improving something whilst already “having your fingers on it” costs a lot less in terms of time and resources than doing so at a later time.

¨      If you don’t improve things as a normal part of “work” (continuous improvement) they will potentially never be improved.

Implications:

¨      Requires time and resources.

¨      People need an environment that allows then to refactor and improve things “as they go”

¨      Management needs to create that environment.

Metrics:

¨      Raw: Amount of refactoring work undertaken.

 

Avoid Under/Over Engineering

Solutions will not be designed to the Nth degree, nor will their designs disproportionately compromise key Enterprise objectives and goals.

Rationale:

¨      If solutions are under engineered there is a danger that Enterprise will not reap the benefits associated with an architecturally driven approach i.e. reuse and flexibility is not free and has to be designed appropriately into solutions.

¨      If solutions are over engineered there is a danger that projects and systems can drown in the drive to achieve the perfect solution or the increased costs and timescales do not warrant the perceived benefit created.

¨      A balance needs to be achieved.

Implications:

¨      Costs, timescales, how the solution is constructed, the functionality it provides and how that functionality is provided need to be considered as a whole in the context of the four EA Strategies (aka the spinning plates of Cost, Flexibility, Risk and Quality).

¨      The key to allow this to occur is the three party partnership behind the successful adherence to this principle, represented by:

¨      Project Manager      - Cost & timescales.

¨      Architect                - How the solution is engineered.

¨      Business Analyst     - What functionality the solution contains.

¨      These roles should exist as a true partnership with no one partner being able to overrule the other and with each role being equally concerned and mindful of the 4 EA Goals. Where common agreement cannot be reached, this principle will be violated and the waiver process will begin.

¨      This will require considerable discussion and agreement to break down the usual “The Project Manager rules the roost” mentality and to provide the environment where this important cultural change can happen.

Metrics:

¨      Survey of PM’s, BA’s and TA’s - “Do you think that PM’s, BA’s and TA’s are working together as an equal partnership or does one role seem to have more power than the other? If so which ones?”

¨      The number of answers where one role is shown to have more ‘power’ than the others.

 

Open Integration

Integration of systems is viewed as a strategic capability separate to each individual system rather than something that is thought of as part of each individual system.

Rationale:

¨      One of the key capabilities to IT successfully supporting the Business is Integration.

¨      Integration is the glue and the key to flexibility - Open, configurable, scalable, resilient, secure.

¨      Integration is the cornerstone and backbone of any agile Enterprise in this world of constant change (business model’s technologies, environmental, regulatory, commercial, etc).

¨      Integration should not be thought of as something secondary that just connects various things, it needs to be thought of as the heart of IT and the Business, connecting packaged applications with legacy, bespoke and external systems.

Implications:

¨      In the same way as Enterprises have teams responsible for networks, servers and databases the Enterprise also should have an integration team which creates new integrations or replaces old integrations and is driven by the Business and project need.

¨      In this way integration is considered, guided and architected on a strategic and infrastructural level and implementation is carried out on a system by system or interface by interface level.

¨      This approach removes the problems associated with a “big bang” approach, but still allows a big picture to be the driving force behind individual integration work carried out as part of other projects. Systems, parts of the Enterprise and individual links can be brought into this systemic integration environment gradually as time, money and business pressures dictate.

Metrics:

¨      Raw: An integration group exists within IT with its own budget.

¨      Raw: Number of shared integration points, systems, technologies, interfaces being used.

Reuse

Reuse of existing people, processes, locations and technology will always be considered and is favoured over buying, adopting or using anything new.

Rationale:

¨      Reuse is the key to low costs.

¨      Must be balanced against increase complexity that reuse introduces.

Implications:

¨      A repository of what exists and the relationships between them needs to be maintained.

¨      This can be difficult and can be viewed as introducing complexity, risk and cost. However, if these risks and costs are weighed against the longer term benefits and costs it usually is in the best interests of the Business to reuse wherever possible.

¨      Reuse of standard things is favoured over reuse of bespoke things.

¨      Reuse of bespoke things should only occur when there is a compelling business expediency to do so.

Metrics:

¨      Raw: The number of times things are reused.

[T : M : IT]

Buy (for reuse) Before Build

Buy Services (for reuse) before buying packages (for reuse) before building (for reuse) .

Rationale:

¨      There is no reason to re-invent the wheel.

¨      Where possible, the Enterprise should lever existing and future functionality offered by IT companies instead of bespoking IT.

¨      Please see the sub principles for more detailed Rationale.

Implications:

¨      Buying (for reuse) means that whenever an individual programme, project or initiative identifies the need to purchase, the requirements and the eventual decision on what is purchased is considered from a more holistic strategic perspective.

¨      The individual programme, project or initiative may encounter a higher cost (both in terms of evaluation as well as licensing and ongoing cost) than it would have if it only considered its own scope.

¨      For selection, the 80/20 rule applies, favouring Services/Packages which satisfy 80% or more of requirements as opposed to a built Services/Package which satisfies near to 100%.

¨      A best of breed approach should generally be followed. However, the numbers of existing vendors, services and packages already in use should be taken into account. i.e. One solution may not be best in breed but is favoured because the vendor is already being used to provide other services or packages.

¨      Vendors supplying other Services/Packages which may be of interest at a later time should be favoured. Services/Packages that have the capacity to be extended or additional modules purchased should be favoured.

¨      Please see the sub principles for more detailed Implications.

1st Buy a Service (for reuse) before Building.

Rationale:

¨      Externally supplied services managed through SLAs tend to be cheaper and make an Enterprise more agile.

¨      This should be tempered by the commodity vs specialist nature of the system being sourced and the security, resilience of the service and the company providing it.

¨      Services that can also provide programmatic access (e.g. using web services technologies) should be favoured over those which provide a purely user interface.

Implications:

¨      Vendors supplying other services which may be of interest at a later time should be favoured. Services that have the capacity to be extended or additional modules purchased should be favoured.

¨      Procurement processes may have to change radically to enable this.

¨      Integration aspects need to be carefully considered.

2nd Buy a Package (for reuse) before Building.

Rationale:

¨      Packaged applications tend to be far cheaper to produce and to support and maintain than bespoke applications.

¨      However, this should be tempered by the commodity vs specialist nature of the system being sourced.

Implications:

¨      Vendors supplying other capabilities which may be of interest at a later time should be favoured. Systems that have the capacity to be extended or additional modules purchased should be favoured.

3rd Build (for reuse).

Rationale:

¨      Bespoke development tends to be the most costly option in terms of up-front costs and support and maintenance costs.

¨      Bespoke developments tend also to be the most risky for non-software house based companies.

¨      Bespoke development can produce significant competitive advantage and so tends to be only considered for USP type functionality or when the functionality required does not exist in the market place. If this is the case, it may be prudent to consider a partnership with a software house to jointly develop a new package that can subsequently be sold.

Implications:

¨      Where a requirement cannot be satisfied by a COTS system or where the requirement for competitive advantages dictates a build solution, a build should be adopted.

¨      The 80/20 rule applies regarding the scope and complexity of the solution.

¨      The system being built should (as much as practicable) allow for easy extension and additions, and also allow the potential to be re-used by other parts of the Business.

¨      A generic and/or data driven application that can easily be extended and re-used should be favoured.

¨      Should adhere to defined quality standards. For example the system should be fully documented to enable it to be supported or changed up by other developers at a later date.

Metrics:

¨      Raw: The number of COTS services in use.

¨      Raw: The number of COTS packages in use.

¨      Raw: The number of bespoke systems in use.

¨      Derived: The ratio of COTS Service to COTS Package to Bespoke.

[T : A]

Relationships & Traceability

Information (Structural & Transformational) used for transforming the Enterprise must be related.

Rationale:

¨      Relationships are the key to understanding the impact of change which enables informed decisions.

¨      IT consists of a large number of different things (e.g. applications, databases, objectives, technologies, etc).

¨      In addition IT operates within a business context of different things (e.g. business processes, people, locations, requirements, objectives, etc).

¨      Whilst these things are important it is the relationships between them that allow the best decisions to be made and allow IT to make sure that what it does has concrete business value. (e.g. mapping Business Objectives to Requirements to Solutions, etc)

¨      The relationships allow impact analysis and the implications of decisions to be made clear.

Implications:

¨      A repository and various tools (EA Modelling, Requirements Analysis, Portfolio Management, etc) are required to enable these different things and their relationships to be modelled effectively.

¨      There will be a learning curve to be able to use these tools.

¨      There will be a population curve while the information is initially loaded.

Metrics:

¨      Raw: Is there an appropriate EA modelling tool in place?

¨      Raw: % of the Enterprise using the EA Model.

¨      Raw: % complete of the Strategy domain model.

¨      Raw: % complete of the Business domain model.

¨      Raw: % complete of the Technology domain model.

Have a Sound Business case

All projects must be supported by a sound business case which addresses the total cost of ownership, plus any wider impacts on the Business and IT.

Rationale:

¨      All too often projects are initiated without a clear definition of the costs, benefits and therefore the true value of a proposition.

¨      Whilst costs and benefits are defined these values can often be “invented” to make the Business case stick and can also often miss the wider strategic and ongoing costs.

Implications:

¨      There are no IT projects, there are only Business projects that have a mixture of IT Change and Business change.

¨      All business cases need to articulate business benefits in business terms

¨      In order for ball park costs to be reasonably representative, a high level view of the solution options and lifecycle costs must be produced at an architectural level.

¨      This view can be produced in a very short space of time, by engaging with architects and business analysts. If it is not possible to determine a broad brush set of options and representative costs, it means that the initial business case would be for an investigation/feasibility study of possible solutions and associated costs, rather than for the solution which would then be contained in a later business case.

Metrics:

¨      Raw: % of programmes, projects and initiatives that have a business case.

¨      Raw: % of programmes, projects and initiatives that include solution options

¨      Raw: % of programmes, projects and initiatives that include lifecycle costs.

[T : C]

Proactive Business Leadership

Business and IT Leaders engage proactively on key IT planning activities.

Rationale:

¨      The Business is the key stakeholder, or customer, in the application of technology to address a business need.

¨      The business needs to be an active participant in order to close the gap between IT and the Business and to allow the Business and IT to operate within a partnership rather than a purely customer/supplier relationship.

¨      In order to ensure IT is aligned with the Business, all areas of the Business must be involved in all aspects of the IT environment.

Implications:

¨      To operate as a team, every stakeholder, or customer, will need to accept responsibility and accountability for developing the information environment.

¨      Commitment of resources will be required to implement this principle.

¨      The business experts from across the Enterprise and the senior technical staff responsible for developing and sustaining the IT environment need to come together as a team to jointly define their goals and objectives.

Metrics:

¨      Raw: Does a model of IT and Business leaders involved in Business Planning exist?

¨      Raw: % of roles, responsibilities and accountabilities defined for each

¨      Raw: % of leaders that have agreed their roles, responsibilities and accountabilities.

¨      Raw: Last 4 Quarters: Did the quarterly Business Planning meeting take place?

¨      Raw: % Business leaders attendance at quarterly Business Planning meetings.

¨      Raw: % IT leaders attendance at quarterly Business Planning meetings.

¨      Derived: % attendance at quarterly Business Planning meetings.

Recognise Responsibilities

Recognise and respect the responsibilities of business departments and the IT department relating to change.

Rationale:

¨      Business departments are best placed to define WHY something needs to change.

¨      Business & the IT Department are best placed, together, to define WHAT needs to change.

¨      The IT department is best placed to define HOW IT change should be implemented.

¨      Business departments are best placed to define HOW business change should be implemented.

Implications:

¨      Business departments are responsible for explaining to the IT department why something needs to change. If the IT department does not understand, the onus is on the business department to explain.

¨      Business departments and the IT department need to work together to determine what needs to change to achieve the desired outcome of a change.

¨      Whilst the IT department is always open to any discussions and recommendations regarding how its change processes could be improved, it is the IT department that will decide what processes must be followed to effect IT change and that these processes may impact business timescales and/or costs.

¨      Whilst business departments are always open to any discussions and recommendations regarding how its change processes could be improved, it is the business departments that will decide what processes must be followed to effect business change and that these processes may impact IT timescales and/or costs.

Metrics:

¨      Raw: % of instances where the IT department is not allowed to follow its change processes.

¨      Raw: % of instances where business departments are not allowed to follow their change processes.

[T : E : IT]

Minimise Customisation of COTS Products and Services

Customisation of COTS packages will only be allowed when their is clear business advantage for doing so.

Rationale:

¨      One of the benefits of buying a COTS package is the reduced maintenance burden and the easy acceptance of updates from the manufacturer.

¨      The more a COTS package is Customised (as opposed to Configured) the more these basic benefits are lost.

¨      A heavily customised COTS package effectively becomes a built application.

Implications:

¨      The Business may have to forgoe some functionality and settle for “what the product can do out-of-the-box” rather than have all their requirements fully satisfied.

¨       

Metrics:

¨      Raw: Number of Customisations done.

 Replace Legacy Appropriately

Legacy Systems will be replaced but only when there is a valid business case for doing so.

Rationale:

¨      Legacy systems are not inherently bad and a wholesale approach to replace them with the latest technology will be avoided.

¨      Replacement of existing/legacy systems will only be done if there is a sound value proposition to do so and if the risks have been properly evaluated.

Implications:

¨      Legacy systems will continue to exist in the Enterprise and it should be noted that this position will not change much over time.

¨      Only the specifics of which systems are legacy will change. i.e. the systems introduced today will be deemed to be “legacy” at some point in the future.

Metrics:

¨      Raw: Number of legacy systems in place.

¨      Raw: A legacy system evaluation framework exists

¨      Raw: % of legacy systems that have been evaluated.

Increase Independence

Applications and services should be independent of specific technologies.

Rationale:

¨      Technologies (Hardware and software) change and evolve over time. As time passes some technologies are favoured over others due to security concerns, scalability, costs, or other important drivers.

¨      Applications which are independent of the technologies they require to operate provide the business with an increased level of flexibility to change technologies when required based on business drivers.

Implications:

¨      Technology Standards are required.

¨      This principle may be difficult to comply with because Commercial Off-The-Shelf (COTS) applications can tend to be platform dependent.

Metrics:

¨      Raw: For each application and service, the number of alternative Technologies that could be used.

¨      Derived: Average number of alternative Technologies per application/service.

Reduce Diversity

The number of technologies should be reduced wherever possible.

Rationale:

¨      The higher the number of technologies used the higher the cost of supporting and maintaining them.

¨      If many technologies are in use, it becomes a necessity for IT resources to have to concentrate on a subset of technologies thereby reducing the flexibility of the workforce.

Implications:

¨      Technology Standards are required.

¨      This principle may be difficult to comply with because Commercial Off-The-Shelf (COTS) applications can tend to increase technology diversity.

Metrics:

¨      Raw: For each Technology, the number of different types in use.

¨      Derived: Average number of instances per Technology.

Increase Interoperability

The level of interoperability between disparate technologies should be increased wherever possible.

Rationale:

¨      Where disparate technologies have to be utilised, interoperability provides the best way of enabling them to work together coherently.

¨      Interoperability reduces the cost of integration and maintenance.

Implications:

¨      Interoperability Standards are required.

¨      This principle may be difficult to comply with because Commercial Off-The-Shelf (COTS) applications may or may not adopt open standards.

Metrics:

¨      Raw: For each Technology, the number of different types in use.

¨      Derived: Average number of instances per Technology.

 

◄◄◄ Previous Page          

          Next Page ►►►





 

© 2008-2016 Pragmatic EA Ltd