Managing the fundamental interconnectedness of things with Enterprise Architecture

Enterprise Architecture is much more than a list of components. Too often one sees diagrams in slide decks that are either simple lists, a layered view of domains, or a graphical hierarchy. And these are supposed to represent the ‘Architecture’?

These visualisations are good to use to inform on the scope and context, but they really only tell us half the story.

The various components (building blocks in TOGAF) will all have a large variety of connections between them to other components. It is these connections that in fact provide the value of an enterprise architecture model, and cement everything together.
An Enterprise Architecture model is a graph of connections. The information and knowledge created in the enterprise architecture model can be viewed from many perspectives and needs to satisfy many stakeholders. Everything is dependent on everything else, and everything is connected in multiple ways. Components never exist in isolation.

An enterprise architecture model is holistic and models the whole enterprise as a sum of the parts, from a variety of different perspectives and stakeholder viewpoints. All enterprises are essentially multi-dimensional, and the connections are the way we can understand all the dimensions.

The connection types can include connections such as:

• Traceability
• Impact
• Association
• Responsible
• Affinity
• Correlation
• Dependency
• Interaction
• Cost
• Accesses
• Motivation
• Evolution
• Need
• Enables
• Assignment
• Realisation
• Uses
• Requires

The name, definitions and set of all possible connection types will be specified in your favourite EA Framework/Meta Model (I.e. TOGAF, ArchiMate, FEAF, MODAF etc.). It’s more common to customise a meta model by adding new connections between existing components that it is to add new component types themselves

Using a well developed EA model, CxOs will be able to look at all the connections help to understand the way the enterprise works as a whole, as a holistic enterprise. The connection provide the cohesion in the model. CxOs can understand all the connections internally between business units, their business model, their business motivation model and externally with their customers and suppliers. And to gain an understanding of how the company fits within the market environment and compares with its competitors. The connections provide knowledge and dynamics.

To get the right answers you need to ask the right questions. The connections between components will provide the answers and support decision making.

Here are some questions that might be asked:

• How are the Business Capabilities realised?
• How do the Business Processes access Data and Information?
• What Knowledge is available to my staff?
• What Business Services are associated with my Value Proposition in my Business Model?
• How does the Product Lifecycle change over time?
• What are the dependencies between Business Capabilities?
• How are my User Needs and Customer Journeys satisfied?
• What components are expected to evolve in the future?
• How do my Business Capabilities compare to those of my Competitors?
• How does my enterprise compare to the Market Offerings?
• When are the Capability Increments realised with Initiatives in the Roadmap?
• Which Initiatives are planned as Programmes and Projects?
• What Resources are assigned to each Initiative or Project?
• What are the Risks associated with my potential Investments?
• What are the dependencies in the Project?

More connections in an EA model will make that model richer and more useful. Connections provide the behaviour in a model.
Connections are not just static but are dynamic and may be changed far more often that the components they link. Modelling dynamic behaviour in an EA model is something that is often overlooked.

An Enterprise Architect is thus someone who makes vital use of “the fundamental interconnectedness of all things”, in order to understand complexity and to find the right answers for the whole enterprise; and who thereby becomes the master of changes, transformations and evolution of the enterprise over time.

Increased interconnectedness in an enterprise architecture model can stimulate innovation and the emergence of new ideas and possibilities.

Strategic Enterprise Architecture provides Intelligence, Analysis and Knowledge

Written by Adrian Campbell

A good analogy for an Enterprise Architecture capability is to think of it as the equivalence to an intelligence corps in the military.
Military Leaders and business decision makers will use this Strategic Intelligence capability to:

• Know what their current capabilities are
• Know the capabilities of the enemy (competitors) are
• Understand and gain awareness of the market situation
• Understand the nature of the environment (the market place)
• Understand the chances of success (costs and revenue)
• Help define their goals and objectives
• Help plan their strategies and tactics
• Help create plans of attack or defence (a roadmap for transformation ad change)
• Help to make new plans as the situation changes (a plan is always the first casualty of war)

The military intelligence corps is responsible for gathering, analysing and disseminating intelligence and knowledge about the military situation.

Enterprise Architecture is a business capability that collects information about the whole enterprise and uses various modelling and analysis approaches to create knowledge about the enterprise, provide advice and guidance to CxOs and heads of business units, and provide intelligence in support of their strategic decisions.

Most enterprises maintain some kind of business intelligence capability to collect information and analyse it, but this is not enough. An enterprise architecture capability is also needed.

For a long time the high level decisions made by executives and senior managers have often purely been based on intuition, personal experience and anecdotes.
Often their experience is 20+ years old and no longer relevant. Unfortunately most CxOs didn’t ever learn about enterprise architecture in their MBA courses, or were never taught about it in the first place. This is woeful ignorance in todays fast moving and complex business environment. Don’t let other players on the golf course make your decisions for you.

Often CxOs and senior decision makers are simply copying the decisions made by their competitors, for better or worse. If one of their competitors is playing with Blockchain, so that must be a good strategy right? Right? Another silver bullet or a waste of money? Does your enterprise architecture capability give you a competitive weapon?

Companies that want to succeed should put their trust in real strategic Enterprise Architecture.

Q. How many CxOs does it take to change a light bulb?
A. None.
– They get their Enterprise Architects to enable the strategic change.

Connections between components in an enterprise architecture model are the basis for identifying, creating and providing knowledge, analysis and intelligence.
In other words, Enterprise Architecture creates the Situational Awareness model for the organisation. The battle map on which the strategies and tactics can be plotted.

Enterprise Architecture models include the strategy, business architecture, information/data architecture, application architecture, infrastructure architecture domains etc.
EA Models also includes a study of the  behaviour of their contacts, customers, competitors, vendors and suppliers, from both a strategic and tactical perspective. Both for the current state and future target state, or indeed multiple alternative future states based on alternative business scenarios. The target operating model is the same as the target enterprise architecture model.

The Enterprise Architecture capability provides valuable knowledge, intelligence and experience of the dynamic changes going on and not just as a static set of deliverables or inflexible process. When the strategic situation changes, then the Enterprise Architecture body of knowledge and intelligence needs to rapidly provide the answers. Keeping pace with today’s dynamic markets requires an Enterprise Architecture capability to enable and deliver a strong strategy and amplify it. A better way to change that light bulb.

Achieving a company’s full potential and stimulating creative needs, innovation and knowledge needs answers to lots of known and unknown questions.
Leaders focus on the most important decisions, answering questions such as:

• What if a competitor does this?
• What if the regulations change?
• What can we do to help?
• How to persuade the customer to buy more?
• How to increase profits?
• How to improve our service?
• How to stay competitive in a changing market?
• How can we innovate?

 

Achieving instant readiness with Enterprise Architecture is better than not being ready at all, or too late.
If you (the CEO) don’t act now to establish an Enterprise Architecture capability now then you will lose out on competitiveness and efficiency.

The most successful leaders in business already have a Strategic Enterprise Architecture capability established, providing the organisation with Intelligence and Knowledge.

Strategic Enterprise Architecture (Intelligence corp) capability includes the following sub-capabilities that enable the most successful leaders in business.

An Enterprise Architecture Capability:

• Provides the ability to envision and visualise an ideal future state based and create a roadmap in order to realise it (situational awareness and winning the war)
• Provides the ability to understand trends that present threats or opportunities for an organisation (countering the enemies threats)
• Provides the ability to identify, analyse, integrate components and connections required to achieve a business strategy (organising your forces)
• Enables and motivates people to work together to realise a strategic business transformation. (ensures success and keeps up morale)
• Enables governance and compliance of strategic relationships with vendors and suppliers, including for cloud services (maintains direction and momentum)

..I love the smell of Enterprise Architecture in the morning. Smells like victory…

 

Cognitive Dissonance

I was reading this today:

http://it.toolbox.com/blogs/ea-matters/is-there-an-enterprise-architect-paradox-surely-is-57728?rss=1

It is a good analysis of the cognitive dissonance between what Enterprise Architects should be doing and the role and situation they often actually find themselves in. The term Enterprise Architect has been hijacked for far too long.

An Enterprise Architect should indeed be a senior leadership role, ideally reporting to the CEO.

 

The trouble I’ve often seen is that mid level executives often think that because they have been promoted into that role that their job title automatically gives them the skills and experience of a real enterprise architect.

 

News Flash: It doesn’t!

 

They do have the skills to set business strategy and provide direction of course (This is a Viable System Model System 5 role). But are they capable of plotting the effect on the enterprise architecture and planning an Business transformation roadmap? Often not so much. They understand the market realities and their customers. The Roadmappping and Busienss Transformation is more the domain of expertise of the enterprise architect (This is a Viabale system Model System 4 role).

 

Subsequently the mid level executives tend to think that real Enterprise Architects who engage with them are somehow after their job (instead of being there to help them) and spend their political capital to push them back to IT where they think they belong.

 

News Flash: Enterprise Architects don’t belong in IT!

 

There should be a Chief Enterprise Architecture Officer with a EA Management Office (or better still called the Office of the CEO) to support them, in the same way that a PMO supports Programme Managers. 

 

My advice is to educate the employers and teach them what an Enterprise Architect really does, and not let them employ other skills and erroneously call them Enterprise Achitects.

 

Its time Enterprise Architecture was taught properly in University MBA courses to the next generation of business leaders. Maybe then the cognitive dissonance will be avoided.

 

 

 

 

Intersection and branding

I’m reading a great new book called Intersection: How Enterprise Design Bridges the Gap Between Business, Technology, and People by Milan Guenther

The book discusses modern Enterprise Architecture perspectives like the Outside In approach and provides a holistic design lead approach that is focus more on the customer than on the underlying applications, technology and infrastructure.

The book also addresses the corporate branding of an enterprise. A successful brand is grounded in the strategic future vision of an enterprise. This strategic vision is also what drives the enterprise architecture initiatives, so it is clear that the enterprise architecture discipline must then provide the key support for understanding what contributes to the brand, what makes the brand successful and what must be done to sustain the brand.  This is a refreshing perspective that tends to get lost in most organisations.

The knowledge of messages, business events, interactions with stakeholders, outside in scenarios, business services and value streams that are defined and designed as part of the business architecture domain will all enable senior executive to understand and develop their brand. A brand is not just the value proposition, the set of products and services offered, but includes the development of the reputation of the enterprise, the customer experience it provides and the trust the customers develop. The book describes this in terms of the form, appearance, communication and behaviour of the enterprise and much more

Enterprise Architecture will have a profound impact on the brand and ultimately on the financial success of the business.

This book is a must read that should be on the bookshelf of every true Enterprise Architect.

See Enterprise Design Framework

How to measure Enterprise Architecture

What is Enterprise Architecture

Enterprise Architecture is essentially a strategic planning discipline for ensuring that all the strategies of an enterprise are well executed. How should we measure it and how it is performing?

First it’s best to clearly understand what Enterprise Architecture is and who it is for.

Enterprise Architecture bridges the gap between those decision makers who come up with new strategies and objectives and those who are involved in enterprise transformation and investments in change. It is about what the enterprise can do now (baseline capabilities) and what it wants to be able to do in the future (target capabilities).

Enterprise Architecture is all about keeping an organisation robust, viable and continuing to satisfy all its stakeholders in the future, who are interested in the enterprise succeeding and continuing to succeed i.e. the CxOs, Shareholders, Customers, Partners, Suppliers etc.

The Enterprise Architecture deliverables are a conceptual blueprint or Target Operating Model that explicitly defines the mission, vision, strategies, objectives, principles, standards and business capabilities at the strategic level, as well as all the other elements (component types) in the enterprise that define how the business operates. These elements include business functions, business services, business processes, scenarios, value chains, value streams, products, application services, applications, technology and infrastructure and are defined within the following Architecture domains:

Architecture Domain	Typical object types in the domain
Market/Environment	Supplier, Partner, Shareholder, Stakeholder, Regulator, Customer, Contact, Prospect etc.
Strategy and Motivation	Drivers, Mission, Vision, Strategy, Objective, Measure, Metrics, Principle, Standard etc.
Business	Business Capabilities, Business Functions (Value Chains), Business Process, Strategic Scenarios (Value Streams), Events, Products, Business Services, Organisation Units, Persons and Roles etc.
Information	Business Information, Application Data, Stored data (Databases, Files etc.)
Applications	Application Services, Applications (Suites, Packages, Components etc.)
Infrastructure	IT Infrastructure (Hardware, Nodes, Networks, Devices, Appliances, Servers etc.Physical Infrastructure (Buildings, Facilities, Vehicles, Machinery, etc.)

Enterprise Architecture also provides several different views of how an enterprise operates and changes, by maintaining a baseline enterprise (operating) model, target enterprise (operating) model(s) and a roadmap of changes to the enterprise’s business capabilities and investments in change ordered within an enterprise transformation roadmap.

Measures and metrics

A large number of organizations use Enterprise Architecture approach in order to plan strategic changes and manage enterprise transformations. Enterprise Architecture is not directly linked to a direct outcome but is usually indirectly related.

One of the major concerns is the failure of many enterprises to actually measure the value of their current or baseline Enterprise Architecture. One is reminded of the old adage ‘What you don’t measure, you can’t manage’. When changes occur as a result of new strategies and target enterprise models, the subsequent enterprise transformation may well be many months or years into the future. Changes are delivered by other groups inside the enterprise or external solution delivery partners. If measures and metrics are not used and actively managed then it becomes rather difficult to compare the old baseline with the new baseline to see what value has been achieved.

Identify the Metrics

The measuring metrics will vary from one enterprise to another. As Enterprise Architecture exists to support the CxOs and decision makers within the enterprise then it is important to define the metrics from their perspective.

Metrics can be identified form a number of perspectives.

Broadly these can be grouped into:

Categories	Description	examples
Internal (Inside Out) metrics	Metrics that measure the internal efficiency of the enterprise’s functions, processes, applications, infrastructure	Cost of business processes Business Process efficiency Operating expenses Productivity
External (Outside In) metrics	Metrics that measure the way the enterprise operates from the perspective of those stakeholders outside the enterprise.	Customer Satisfaction Sales per customer Profits per transaction
Change related metrics	Metrics that measure how well the enterprise transformations are being achieved	Profits per Investment in change Percentage of the target EA Model that has been implemented Percentage strategies realised

More detailed metrics can defined for each Architecture Domain. Here below is a discussion of some of some potential metrics used for measurement of their enterprise architecture’s value.

CxO’s Metrics

The Enterprise Architecture is by definition the architecture of the enterprise, so the metrics also need to be defined from the enterprise or business perspective. The CEO and other CxOs are responsible for managing the enterprise so the metrics need to be ones that they are interested in and keen to measure. These may include:

• Completed transactions
• Revenues
• Operating expenses
• Profit
• Revenue per dollar of operating cost
• Profit per completed transaction
• Productivity
• Profits per investment

The trends and rates of change in the numbers are often more important than the actual numbers.

If the enterprise strategies and therefore the target Enterprise Architecture are not having an effect (directly or indirectly) on the numbers that the CEO is interested in, then the Enterprise Architecture is not being effective.

Customer experience metrics

One of the biggest contributions to Enterprise success and profits is the overall customer experience and satisfaction. There are three categories of Customer experience metrics:

Category	Description	Examples
Descriptive Metrics	About what happened when a contact, prospect or customer engages with the enterprise	Call and email volume Average call time Calls lost Website visits Average transaction values Average calls per customer
Perception Metrics	What did the contact, prospect or customer think about what happened	Customer satisfaction with their experience Goal completion rate Complaint resolution rate
Outcome Metrics	What will the customer do as a result of what happened	Likelihood of recommending Likelihood to purchase Actual purchases made Returning customers Churn rates Value provided

These metrics measures how happy a customer or prospective customer is with the enterprise’s value proposition (their products and business services). What value is provided to the customer? This measure is becoming common with value based pricing approaches. How easy is it for the customers to do business with you? Do the enterprise business services provide for the needs of the customer’s own internal processes? Customer Satisfaction can be increased by better communication with them through their preferred channel, so a measure of Customer communications (messages and interactions, social media) can be useful.

Cost Benefit

Cost/Benefit ratio to measure the value of any new or changed business capability. This is used to compares the amount of money spent on the transformation (costs) to the amount of money that is being saved after the implementation of the changes (Benefits). These metrics are often measured in terms of money, but in fact the benefits may be non-monetary values such as increased sales, improved customer satisfaction, reduction of risks, increased flexibility, and improved platform for future change.

Productivity and Effectiveness

CEOs will be concerned with the effects of Enterprise Architecture and new investments on production, efficiency and effectiveness. Metrics in this area can focus on:

• Reducing time to market for new investments in change
• Integrating and improving business processes across the enterprise (including with partners)
• Improving the ability to integrate data and interfaces across the enterprise (including with external partners)
• Improving the ability to reuse business functions, business processes and application services
• Increasing agility, flexibility and ability to rapidly change in the event of new strategic scenarios occurring
• Increasing standardization
• Reducing the time taken to develop solutions by maximizing reuse of enterprise architecture models

Governance and compliance

Enterprise Architecture ensures that the strategies of the enterprise are realised.

How many business capabilities are being created, updated or removed? What capability increments are being turned into investment proposals and providing the mandates for new programmes and projects? How many capability increments are being delivered by the solutions that have been subsequently designed and developed? How well are the solutions in compliance with the target enterprise architecture model?

Knowledge

The Enterprise Architecture function will create a well-populated repository of knowledge about the current state of an enterprise and its planned future state vision. The enterprise Architecture models provide a knowledge base for CEOs, CxOs and other decision makers that provides answers to their questions. In essence an enterprise architecture model needs to be designed to answer all their potential questions. How well does it achieve that?

These questions can be about gaps, impacts, dependencies, probabilities of success and failure, risks, costs etc. One of the major concerns of Enterprise Architecture is to reuse the knowledge, information and data as required by various processes and applications throughout the enterprise. Metrics can include the percentage completeness of this knowledge base. How easily and readily available is this knowledge throughout the enterprise to those stakeholders who need it?

A Common Vision of the future state

The whole purpose of Enterprise Architecture is to align investments in change with the strategies for the future of the enterprise. The target Enterprise Architecture Model is the target operating model that provides a common vision for all parts of the enterprise, including internal business units and external partners. How complete is this model and all the associated diagrams and documentation? Is it readily available?

Enterprise Transformation

The target enterprise architecture model will reduce the time it takes to conduct a particular enterprise transformation, implement new and changed business capabilities and reduce solution design and delivery time and development costs by maximising reuse of the enterprise level models. It will provide standard components and ensure maximum reuse of them across the whole enterprise. Over time the enterprise architecture will ensure faster development, fewer failures and better alignment to strategic enterprise level requirements and continual improvement.

Qualities

The Enterprise Architecture is often focused on improving or enabling various characteristics and qualities in the future.

Metrics can be based on these qualities can include:

• Efficiency
• Robustness
• Reliability
• Viability (ability to remain viable in a changed environment)
• Flexibility (ability to automatically adapt when unexpected external changes occur)
• Complexity
• Agility (Ability to adapt to changing business needs)
• Adaptability
• Ease of integration
• Amount of reuse
• Support for innovation
• Service level
• Quality
• Accuracy

In conclusion

Enterprises need to measure Enterprise Architecture by how well it improves the performance of the whole enterprise, meets its business needs, and supports its strategies and investments in change.

Going from just good enough to being great

I recently saw a Forrester blog entry from George Colony at: http://blogs.forrester.com/george_colony/12-08-27-enterprise_architects_for_dummies_ceos

And recently I’ve been reading an interesting book called Good to Great by James Collins. See http://en.wikipedia.org/wiki/Good_to_Great

The Forrester blog talks about succeeding with realizing the business strategy by involving enterprise architects, whereas the Good to Great book doesn’t mention enterprise architects but just talks about needing the best people to achieve great things.

It raises the question ‘Does an organisation need enterprise architects to achieve greatness?’, and ‘What does an enterprise architect need to do to be great themselves?’.

An Enterprise architect will certainly bring a logical enterprise-wide view of strategic change, usually cutting across organisation boundaries. They will look at the strategic design of the enterprise vision in terms of interconnecting business capabilities, where a business capability is a similar concept to a ‘system’ as described in system thinking and the viable system model. They will help with the business thinking.

But is this how senior executives see strategic change?

I’ve experienced organisation restructuring close up at a large number of organisations over recent years and in all cases, the enterprise architects were not involved at all. The re-structuring tends to be done along business functional lines. Nothing wrong with that perhaps, but it does tend to bake in the old silo boundaries and restrict cross functional reuse of business capabilities.

Is this good or great, or merely good enough?

How do senior executives see enterprise architects?

Enterprise architects work with the executives, senior business stakeholders and heads of all the business functions to build a holistic enterprise architecture vision model that links the enterprise’s mission, business strategies and priorities to the current and future needs in an efficient and viable fashion.

For enterprise architects it’s typically not sufficient to merely produce a good vision and good roadmap, but the focus should be on producing a great one that is robust and viable way into the future.

Quick and dirty is not a great approach and is often a waste of money from a long term enterprise perspective.

There will inevitably be a sort of creative tension between the various lines of business and enterprise architecture. Part of the reason for this this is that the lines of business invariably take a top down view and the enterprise architects are naturally working across functional silos. There is often a sort of conflict of overlapping RACIs, a clash of who appears to be responsible for making a decision. Generally that is easy, it’s the business strategy owned by the business that makes the decisions.

But as George Colony observes in his blog, it’s the enterprise architects that span both the business and technical domains and act as ‘an internal trusted advisor who marries the best interests of the business with long-term technology strategy’.

An analogy is within the realm of politics, where the politicians take the decisions helped and supported by their advisors. Also like politics, the lines of business are often challenging each other and pandering to popularity polls.

This raises another thought, should an enterprise architect be popular or be professional? Can they be both at the same time? Should an enterprise architect indeed be a kind of politician following the whims of the time, or should they be seen to be standing up for doing the right things for the future?

Tactical short term changes are invariably much easier to build a business case and obtain investment for than multi-year long term strategic changes will ever be. Should an enterprise architect just focus on short term fixes, or do their job and focus on strategic change. Like a politician, should an enterprise architect aim to be liked and popular, or respected for their work furthering the best interests of the enterprise?

It’s rather like a politician who can only achieve changes within a single parliament, and therefore shies away from embarking on initiatives that will take a long time and multiple parliaments to achieve. Should an enterprise architect just be popular and play politics? Does this make an enterprise architect great? In fact, what does make a great enterprise architect? Ideally 40% of our job is communication. Maybe communication really means playing to the populous crowds? Does promising bread and circuses make things great?

James Collins says that good to great companies follow the principle of “First Who, Then What” and hire good people. Collins talks about good CEO’s typically have much humility. So maybe a great enterprise architect should also be humble? Perhaps a great enterprise architect is one who makes great decisions? But then if it is only the lines of business who make the decisions, what then? Often the enterprise architect is not in the position to make enterprise level decisions, only recommendations.

To be great enterprise architects should be focused on being neutral and not taking sides, working faithfully for the enterprise as a trusted advisor, taking the enterprise in whatever direction it chooses to go at whatever speed it wants to go, realizing the collective enterprise vision. In turn, the enterprise needs to treat enterprise architects as true trusted advisors and not just delivery agents. Enterprise architects should follow a set of principles, be honourable, forthright and avoid compromise, keeping the organisation honest. Maybe in doing that they won’t always be popular but they will be doing their job.

It has been said that ‘business leaders rarely succeed in marrying empirical rigor and creative thinking’, so it is the enterprise architects task to help them do this better and achieve a great enterprise and not just one that is just good enough. Just good enough is never good enough.

In my opinion, without enterprise architects, an enterprise cannot easily become great and may only achieve greatness through simple luck.

The purpose of Enterprise Architecture

I’m often confronted by solution architects, IT and technical architects who don’t understand what Enterprise Architecture is all about. They usually misinterpret enterprise architecture from their own perspective as some kind of system design of ‘enterprise’ scale IS/IT systems and become frustrated when they discover that it is really something else. It often turns out that they are not usually working at the right level or with the right stakeholders in their organisation to be true enterprise architects. They are not working with the leadership team but within the scope of a small development project.

They can’t therefore see the wood (the ‘Enterprise’) for the trees (a project), let alone the helicopter view…

Enterprise architecture is in reality one of the most powerful management approaches that can be used by an organisation. It is not intended to be used (only) at a solution or project level but for the big decisions that an organisation’s leadership team have to make. The leadership (i.e. the C-level executives, and heads of divisions etc.) have to make the decisions based on the facts and knowledge base (the Enterprise Architecture repository) delivered by the enterprise architecture function. Those decisions are supported by the enterprise architecture function planning their execution in the EA roadmap. Each initiative in the EA roadmap is typically a new or changed Capability or Capability Increment (see MODAF and http://www.mod.uk/NR/rdonlyres/E43D93F6-6F43-4382-86BD-4C3B203F4AC6/0/20090217_CreatingCapabilityArchitectures_V1_0_U.pdf).

Typically the focus of Enterprise Architecture is on:

• Increasing the return on business and IT investments by more closely aligning them with business needs.
• Identifying areas for consolidating and reducing costs
• Improving executive decision making
• Increasing the benefits from innovation
• Delivering strategic change initiatives
• Managing business transformation activities

The Enterprise Architecture is also characterised across the following multiple dimensions:

• Direction: Enterprise Architecture is focused on strategic planning (i.e. business transformation, strategic change programmes) and not on operational change (i.e. run the business, six sigma, lean processes)
• Scope:  Enterprise Architecture is focused on the whole of the business (i.e. the Business Model and Business Operating Model) for all business and IS/IT functions, and not just on the IS/IT components.
• Timeline: Enterprise Architecture is focused on the long term view of the future scenarios (up to 3/5 years in the future) and not just on a short term view of current state. Enterprise Architecture is focused on a roadmap of changes to an organisation’s capabilities.
• Value Chain: Enterprise Architecture is focused on the whole of the enterprise (i.e. the extended organization and value chain) and not just on the scope of a delivery project
• Stakeholders: Enterprise Architecture is focused on the needs and concerns of the C-level executives (CEO, CIO, COO etc.), business executives, corporate and business strategists, investors, strategic planners.

(ps. I tried to draw a diagram to illustrate where Enterprise Architecture lies on these dimensions but couldn’t visualise a multi-dimensional space…)

So overall, the primary purpose of Enterprise Architecture is to support strategic change such as :

• The introduction of new customer and supplier channels such as  eCommerce
• The consolidation of the existing portfolio of people, processes, application and infrastructure etc.
• The reduction of costs and risks, ensuring the enterprise will remain viable and profitable
• The design of a new organisation, business model and business operating model.
• The due diligence for mergers and acquisitions and management of the resulting integration programme.
• The development of smarter and more effective systems (not just IT systems).
• The introduction of shared services and applications.
• The introduction of new technology, platforms and infrastructure such as SaaS, Cloud etc.
• The introduction of regulatory and legal changes such as Basel 3

 

In my future blog entries I will explore how Enterprise Architecture supports some of these areas.

The first one will be about how Enterprise Architecture is used to support Due Diligence activities prior to mergers and acquisitions.

 

Strategy Planning and Enterprise Architecture – dealing with the devil in the detail

Enterprise Architecture is all about supporting strategic planning and business transformation activities, although many organisations seem to almost wilfully forget that this is one of the main purposes of Enterprise Architecture if not the most important one.

A business strategy is a long-term plan of changes for the whole enterprise which will address things like offering new products an business services, dealing with new customer or market segments, opening up niche opportunities, growth via mergers & acquisitions, cost consolidations and increased efficiencies. See http://en.wikipedia.org/wiki/Strategic_planning  and http://en.wikipedia.org/wiki/Business_transformation

Enterprise Architecture primarily focuses on what an enterprise needs to do in order to stay viable, efficient and profitable in the future. In Viable System Model (VSM) terms, Enterprise Architecture is a System 4 type of system. See http://en.wikipedia.org/wiki/Viable_system_model

Enterprise Architecture bridges the gap between new strategy ideas and the execution of those ideas, in the same way that the intelligence corp in the military provide intelligence about current and future capabilities to the generals and ensure that the appropriate planning takes place in order to win the military campaigns.
Many organisations without an Enterprise Architecture function will risk failing to properly implement or deliver the on their business strategy.

It is frequently reported that many strategic ideas and initiatives identified by C-level executives are never properly implemented or seen through to full operation by the business units. That big picture of the business strategy on the white board in the CEO’s office or a high level presentation can look deceptively simple in a board meeting, but as they say ‘the devil is in the detail’. The C-level executives are responsible for seeing that the strategy is implemented, but it will be the Enterprise Architect that works out the detail.

Organisations need to know where they are now and create a baseline Enterprise Architecture model of their current state, then create a future target Enterprise Architecture model and do impact and gap analysis between them. The future state Enterprise Architecture model often needs to contain not just one single future target model but multiple complementary or competing models of  the many future scenarios that are likely to have  been developed using Scenario Planning techniques. See http://en.wikipedia.org/wiki/Scenario_planning

Strategic business transformation can be hard. Enterprise Architecture makes it far easier to answer questions such as:

• What Strategic initiatives are needed to fill the gaps found and address risks and issues?
• What new or changed business capabilities will be needed?
• What needs to be done when?
• How does one prioritise the different strategic business initiatives on an Enterprise Architecture roadmap?
• When are these investments in change going to be delivered?
• How will the initiatives be funded?
• What are the dependencies between the strategic initiatives?
• How will the business model be changed?
• How will the target Business Operating Model be changed?
• What organisation units and business functions need to be changed?
• What value chain and value streams need to be changed?
• What are the costs and potential revenues?
• How feasible is the business strategy?
• What feedback mechanisms between ‘systems’ will be needed?
• How will change be governed and how will compliance be assured? (i.e. how do we overcome resistance from difficult stakeholders, and the ‘Not invented here’ anti pattern?)
• What controls, KPI’s, CSF’s, incentives, bonus structures will be needed?
• What changes to the principles and standards will be needed?
• How do we align people, processes and technology?
• What other things have we forgotten?

I recommend reading the books:

• ‘Making Strategy Work: Leading Effective Execution and Change’ by Lawrence Hrebiniak and
• ‘Enterprise Architecture As Strategy: Creating a Foundation for Business Execution’ by Jeanne Ross and Peter Weill.

The Viable System Model is the missing theory behind Enterprise Architecture

I am currently involved with the EAST group (an outreach group of SCiO http://www.scio.org.uk/ ) which is looking at the overlap between Enterprise Architecture and System Thinking, and in particular the Viable System Model (VSM).

The Viable System Model has been around for many years, coming out of Stafford Beer’s work  http://en.wikipedia.org/wiki/Anthony_Stafford_Beer

This diagram looks complex at first but you can also read a very accessible description of the Viable System Model at http://www.scio.org.uk/resource/vsmg_3/screen.php?page=0cybeyes and at http://en.wikipedia.org/wiki/Viable_system_model

An excellent book to read is Patrick Hoverstadt’s book  ‘Fractal Organization: Creating Sustainable Organizations with the Viable System Model’  See http://amzn.to/mjHz6F

But what is the Viable System Model?

The Viable System Model is a recursive view of five main systems within an organisation.

The word ‘System’ here doesn’t mean an IT system or an information system but has the more generic meaning of the word ‘System’. See http://en.wikipedia.org/wiki/System

Those five systems are concerned with the following functions and capabilities:

System 5	Policy, ultimate authority, identity.
System 4	Adaptation, forward planning, strategy.
System 3	Internal regulation, optimisation, synergy.
System 2	Conflict resolution, stability.
System 1	Primary activities.

System 1 systems within an organisation are realised by those organisation units that actually make products, deliver business services and create value.

System 2 systems are those organisation units that provide the coordination functions.

System 3 systems are those that provide the audit and operational control functions.

System 4 systems are those that look forward to the future and the external environment.

System 5 systems provide the strategy and business direction.

The Viable System Model is recursive so that the same five systems appear at all levels within an organisation, but it’s easy to see equivalent VSM systems at various levels in an organisation.

At at the top level it is possible to see that the Executive Board is a level 5 system, the general management are mainly level 3 systems, the system 2’s are the programme managers, project managers and solution architects. The system 1’s are the operational service delivery units and project teams.

Where does that leave Enterprise Architects? Well the Enterprise Architect function is essential a system 4 system with it’s focus on strategic planning for the long terms view and creation of roadmaps of strategic initiatives.

The strategic Enterprise Architects (system 4) with their long term, external and strategic focus work in co-operation with the Solution Architects (system 3) with their immediate operational, internal, lean, design and delivery focus.

It’s clear to see with our Viable System Model lens that solution architects and enterprise architects are not doing the same job but a completely different job.

From an Architecture Continuum perspective (TOGAF9  http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap39.html) then the Viable System Model is an example of a generic Foundation Architecture. and a thus a key architecture to reuse when designing organisation specific target enterprise architectures.

The SCiO group has developed the SCiO Organisational Maturity Model http://www.scio.org.uk/OMM which is based on the Viable System Model.

This can be used for assessing the strengths and weaknesses in your enterprise, looking at how efficiently it is working today, both in the immediate operational perspective but aslo the log term viability of your enterprise in the face of changing external market and business environment.

The on-line questionnaire for the SCiO Organisational Maturity Model addresses six aspects of the Viable System Model:

• Operations
• Co-ordination
• Resource and Performance Delivery
• Monitoring
• Development
• Managing strategy

The outcomes are expressed in terms of  a measure of maturity across those six dimensions and a diagnosis of which Archetypes (i.e VSM anti-patterns) apply to your enterprise and which need to be addressed.

Unlike Lean manufacturing which only focuses on operational efficiencies in the the lowest level System 1, System 2 and System 3 systems within an organisation, the Viable System Model looks at the whole enterprise from a recursive perspective which is more sound and holistic.

In some ways it is surprising that it hasn’t yet reached a tipping point within organisations or their enterprise architects. Maybe this is because everyone is too focused on the day to day need for operational efficiency and approaches such as Lean Manufacturing (http://en.wikipedia.org/wiki/Lean_manufacturing) and forgets about planning for the future. This is the difference between being reactive and proactive.

Further reading at http://coherencyarchitect.com/2011/01/29/the-fractal-organization-in-an-enterprise-architecture-point-of-view/

and the excellent book: The Service-oriented Enterprise by Tom Graves,  http://amzn.to/kAzR7F

The next time you are challenged on the purpose and value of Enterprise Architecture, then answer that it’s the difference between the external and future oriented perspective of the VSM system 4 as opposed to the inside and now, operational efficiency perspective of system 3 and service delivery perspectives of  system 1 and 2.

As a system 4 system, the enterprise architecture function focuses on:

• Supporting the business strategy developed by system 5
• Analysing strategic change initiatives
• Planning and creating strategic road-maps
• Scenario analysis
• Assessment of future risk, agility and viability of the enterprise
• Coordinating with system 3 systems (i.e. portfolio and programme management, project management and solutions architecture)
• Governing the realisation of those strategic changes and development of new business capabilities.

The more one looks at the Viable System Model, the more it looks like the unifying theory behind Enterprise Architecture.

Enterprise Architecture as the Office of the CEO

We are used to the idea of a Programme/Project Management Office (PMO) but often organisations fail to understand (or perhaps deliberately misunderstand) what the Enterprise Architecture function does. I propose that the Enterprise Architecture function is, in effect, an Office of the CEO, or an Office of the CEO and Strategic Change Management.

The book ‘Enterprise Architect as Strategy’ (http://www.architectureasstrategy.com/book/eas/ ) gives us the right way of thinking and talking about what enterprise architecture is for – creating a foundation for the execution of the Business Strategy.

This book is an essential read for senior executives, business leaders and enterprise architects.

Many people within an organisation will understand the big picture view of the business strategy, such as the CEO of course, but perhaps only at a shallow level of detail.

Would the C-level executives understand all the potential nuances and wrinkles that come with that business strategy? Perhaps not unless they were a ‘details’ person.

What does the CEO do? They will spend time in evaluating ideas, formulating the mission and vision of their orgnaisation, innovating the business model to ensure the company remains competive in their market, looks for future opportunities for expansion and carving out a niche market.

It is the Enterprise Architect who has the job of maintaining the big picture on the behalf of the CEO, in sufficient detail to ensure that it becomes a knowledge base to support the executive’s decision making and help them to realise the business strategy and govern the implementation of that strategy.

In this way the Enterprise Architecture function is effectively the Office of the CEO,  providing strategic support to the CEO and the other C-level executives. It’s also worth stating here that effective companies focus on enterprise architecture and don’t jump straight into IT architecture. Enterprise Architecture is not the same discipline as IT Architecture.

We can look at the the Enterprise Architecture function in terms of Deming’s Plan-Act-Do-Check process improvement process:

PLAN

The CEO and other C-level executives will stablish the mission, vision, goals, objectives, principles and metrics to identify the main outcomes of the business strategy.

The Enterprise Architect will help executives, business leaders and strategic planners to develop the business model, operating model, and other enterprise architecture models supporting business model innovation

DO

The CEO and other C-level executives will evolve and innovate the Business Model.

The Enterprise Architect will take the business strategy and business model and support the development of the target operating model,  communicate the business strategy, model the target and interim enterprise architecture models, plan an EA roadmap of strategic initiatives, identify and define the required capabilities, define the mandates for the investment programmes and key projects, define standards and process improvements. They will usually define the IT strategy to ensure that it fits with the business strategy rather than being developed in isolation (as unfortunately often happens).

CHECK

The Enterprise Architect will perform EA governance, compliance and design assurance against those programes & projects implementing the strategic changes and new capabilities. They will perform gap analysis and impact analysis, measuring the performance and compare the results against the expected outcomes.

ACT

All the while the Enterprise Architect will report to the CEO and act as their trusted advisor. They will analyze the gaps, risks, costs, issues, assumptions and dynamics to determine their cause and determine where to apply further strategic changes in the next iteration of the cycle and improve the overall maturity level of the enterprise.

The mission of Enterprise Architecture is to improve the implementation and excecution of the business strategy, ensuring that the enterprise will survive, continue to develop and remain profitable in the future.

An interesting example to look at is the US Department of Health and Human Services which has established an Office of Enterprise Architecture as part of the Office of the CIO.  http://www.hhs.gov/ocio/ea/index.html

Activities of the Office of Enterprise Architecture

As the the book ‘Enterprise Architect as Strategy’ says – ‘When it comes to executing your Business Strategy your Enterprise Architecture may matter more than your strategy itself… ’

Making Strategy Work with Enterprise Architecture

If you want to execute a business strategy then you’ll need an Enterprise Architecture function.

Enterprise architecture (EA) is about change – strategic change in an enterprise.

But not exogenous change – reactive change forced on the enterprise by outside exigencies – although that sort of change and those external forces may be taken into account. No, enterprise architecture is about endogenous change – directed, planned, strategy-driven change within the enterprise.

Enterprise architecture is about describing the desired future state of the enterprise and plotting a course towards that position in enterprise ‘state space’ known as the Target Architecture.

Recently there was a long and fruitful discussion on LinkedIn, between practitioners, of the proposition that “EA is not the glue between IT and “The Business”. EA is the glue between Strategy and Execution.”. Aside from the questions of whether “glue” is the right metaphor and the possible mereological fallacy of considering IT and “The Business” as separate entities in need of glueing, the proposition is also something of a false dichotomy.

The two aspects – Business-IT Alignment and Strategy Formulation-Strategy Execution are neither mutually exclusive nor independent from each other. So, as with many false dichotomies, the ‘correct’ answer is “both and neither”. But in terms of importance to the business or enterprise, being the glue between strategy formulation and its (presumably) successful execution is critical whereas getting IT aligned to the business needs is only a very useful and desirable outcome.

But the question this immediately raises is what exactly it means to be the glue between strategy formulation and strategy execution – which despite the lengthy discussion was not really answered.

How exactly does EA help strategies get executed – and executed well?

The standard ‘authorities’  [like “Enterprise Architecture as Strategy” by Ross, Weill and Robertson] actually don’t help all that much – offering general aphorisms like “First build your foundation for execution” and “Define your operating model”. Well, yes – but what does that mean and how does that get your strategy off the drawing board and put into effect?

In recent weeks I’ve been reading a somewhat ‘non-standard’ EA textbook, by a professor at Wharton Business School which addresses exactly this problem.

That book is “Making Strategy Work – Leading Effective Execution and Change” – and even though Dr. Hrebiniak never mentions the term, I would contend it is a book about Enterprise Architecture because it is about change, strategic change, in an enterprise.

Towards the end of chapter six he provides a very plausible answer to the question of how strategy execution is glued to strategy formulation in the form of a “Strategy Review Process – Planning, Execution, and Controls” [Figure 6.2]. See http://www.amazon.com/Making-Strategy-Work-Effective-Execution/dp/013146745X

In essence the process is an adaptive closed-loop feedback control (socio-technical) system that seeks to bring actual business performance towards that demanded by the ‘control’ input of strategic objectives through the following six steps:

1) Strategy Formulation – including resource capabilities and constraints, strategy and goals, industry forces and competitor analysis

2) Strategy Planning and Execution – including meeting the demands of strategy, [changing] organisational structure, Integration Requirements and Methods, Information Requirements, Hiring and Training People [Developing organisational skills and knowledge] and Appropriate Incentives

3) Review of Actual Business Performance – including emergent deviations from the planned strategy

4) Cause-Effect Analysis and Learning

5) Feedback / Change – including changes in strategy and changes in the capabilities of the organisation

6) Continuation and Follow-Through – including integration and review of strategy changes, resource (re)allocations and agreement on business performance objectives and measures

Where step 6 feeds back and leads back into step 1, closing the loop. Dr. Hrebiniak asserts “Every organisation must fashion its own strategy review process. It’s not a luxury but a necessity. It’s that important. …It supports execution”. I’m not sure how much the professor is hyping his own process – but if the strategy review process is the enterprise’s only formal link between formulation and execution, I‘d say there is little hyperbole – it really is that important. Execution is delivery, formulation is just structured aspiration.

So what has this to do with Enterprise Architecture?

Step 1 is strategy formulation – and it is the usual process of matching internal and external analyses of the enterprise for the future. Enterprise Architecture is *the* key contributor to the internal analysis – the resource capabilities and constraints are (should be) described by the EA model, the strategy and goals are the EA (model) Motivation Decomposition.

Step 2 is essentially the strategic planning of change – including people, processes and technology wrapped up as  organisational ‘capabilities’, or business architecture, information architecture, functionality (or ‘applications’) architecture and technology architecture. Many would regard this as definitively Enterprise Architecture. Not only that, the changes are described by the Target and Current Enterprise Architectures (models) and a number of intermediate Transitional Architectures and the differences between them. The planning process is the EA gap analysis process.

This is EA as a strategic planning for change function for the enterprise.

In step 3 – the intended target or transitional enterprise architecture (model) provides the baseline against which actual achievement can be objectively measured.

In step 4 – well, correlation is not causation; it is actually remarkably difficult to determine the contributory causative factors to any particular outcome or effect. EA has a role in assessing how much of the (change in) business performance achieved is down to what changes in the enterprise.

This is EA as the basis for impact analysis of change. Did investing in that software development really cause the increase in sales of snow-shovels or was it that the weather was more inclement than most people anticipated this year?

Step 5 brings in capabilities again. EA should describe the relationship between the organisational capabilities and the resulting business performance. EA is there to help assess what returns investing in particular capabilities is likely to achieve – and therefore find the optimum investment pattern.

And step 6 is again into describing the architecture of the enterprise as it is now and how we want it to be – and how we are going to measure the progress towards the ‘to-be’.

From this perspective, Enterprise Architecture can be seen to suffuse the entire Strategy Review Process, making it systematic, rigorous and cohesive – like a resin glue.

So if you are the CEO of a company that does not have an Enterprise Architecture function or a Strategy Review Process, presumably you think all you need do is formulate and promulgate a strategy and the execution will take care of itself?

No?

Me neither – I think you need some glue.

by Ian Glossop, Enterprise Architect.

Smart Enterprise Architecture

Organisations need a new paradigm. In order to survive, old dogs are going to have to learn new tricks.  They need to start fundamentally thinking about how to change the way in which they innovate, think and make decisions. To allow future operations to be more efficient, c-level executives and senior managers will need more accurate and real time information for better decision making and to optimise business strategy execution.

At a strategic level they need to leverage existing expertise and technology to deliver the capabilities they desire. Organisations will need to provide their decision makers with access to enterprise knowledge, allowing them to gain the insights that will enable the best alignment of operational performance with business strategy and objectives.

For effective knowledge management and information sharing they will not only need Enterprise Architecture, but will need Smart Enterprise Architecture.

The vision of Smart Enterprise Architecture is an approach that will enable information to be captured in real time, analyzed and proactively used to enhance business performance through predictive risk-based decision-making.

Sign up to Download the Diagram

See also IBM on predictive Analysis at  http://tinyurl.com/39sdn3p

In the past, the technologies used in organisations have been relatively simple, now organisations will need to become ‘smart’.

What can make Enterprise Architecture smart is not new technology in itself, but rather innovative ways of combining existing state-of-the-art measurement and feedback mechanisms that can respond to changing conditions and allow an organisation to be agile and adaptable.

This vision is similar to that of Stafford Beer in his Viable System Model which he first described back in 1972. A Viable System is any system organised in such a way as to meet the demands of surviving in a changing environment, primarily by being adaptable. See http://en.wikipedia.org/wiki/Viable_System_Model

If he was still around today Stafford Beer would probably have been an enterprise architect.

To make Enterprise Architecture smart we have to gain value from examining the approach to process optimisation in other industries, such as the car industry.

In the not too distant past when a car was serviced, the diagnostics and fine-tuning of its systems were performed manually, with simple tools, skills & experience and heavy lifting. By contrast, the modern car engine is simply plugged into a computer diagnostic system which interfaces with the car’s onboard computers. The computer is linked to dozens of digital sensors that instantly monitor all the car’s systems and informs the mechanic what adjustments are needed. The car’s computer continuously controls its engine management system in real time as you drive along, optimally adjusting the engine parameters to adapt to the driving conditions and your driving style to maximise economy and minimise emissions.

So for Smart Enterprise Architecture we need the same kind of continuous state-of-the-art measurement and feedback value stream to control and adapt the organisation in real time. The following diagram illustrates the use of Enterprise Architecture in a continuous value stream or ‘value loop’.

See paper http://tinyurl.com/2em3k3m and also Deming’s Plan, Do, Check & Act cycle and Six Sigma’s Define, Measure, Analyze, Improve & Control cycle.

Once the Enterprise Architecture models are established it will be possible to make them the centre of predictive analysis, enabling the generation of strategic options in response to the real time changing behaviour of the enterprise.

Those strategic options can be kept in compliance with the business strategy, goals and objectives to continuously provide the best way to optimise value.

Organisations will need to look outside themselves and their traditional partners to find new skill sets and capabilities in order to develop a Smart Enterprise Architecture.

Join the Enterprise Architect community

This post is also available at http://tinyurl.com/29qunfd

Real Enterprise Architecture or IT Architecture?

Organisations always have an implicit architecture, but not always an explicit architecture.

If they do have an explicit architecture, the chances are that it is an IT Architecture that has evolved over the course of hundreds of little decisions made by developers and project managers over the years.

Perhaps these decisions have been made by the CIO in consultation with the IT department and the business who ultimately have to pay for them.

The question is this IT Architecture the right architecture for the organisation?

Many of the business leaders certainly don’t think that they have the architecture they need or deserve.

Increasingly I hear business leaders talk of IT as part of the problem and not part of the solution.

The move to outsourcing and cloud computing is a knee jerk reaction by the business to bypass that slow, constraining old IT department they don’t like and think is too expensive.

The IT Architecture then represents what has happened in the past.

In many cases it’s not quite the fault of the IT department.

They’ve tried their hardest over the years and have done away with business and systems analysis in favour of Agile (the new quick and dirty) approaches in blinkered projects.

This has meant that many IT systems and processes have ended up as string and sealing wax solutions, each in their own silo, as one bank told me last year.

It’s easier for the business to hack together an end user computing (EUC) solution (i.e. Access or a Spreadsheet) or buy a cloud based solution outside the control of IT.

These are unstructured and dangerous, but within limits have given the business the control and responsiveness they wanted.

However ultimately these non-IT solutions hinder an organisations ability to execute its latest business strategy.

So the concept of Architecture is brought back to sort out the mess. But the IT Architecture has not had the impact at the right levels to have the right effect and be the right architecture, so we need something else.

To get the right architecture, organisations should focus on ‘real’ enterprise architecture, not IT architecture, and certainly not IT Architecture just renamed as Enterprise IT Architecture.

Top performing organisations use Enterprise Architecture, with it’s business and strategy driven approach, to help them mould their business strategies, identify the goals and objectives, guide the development of their Business Models and Business Operating Models, establishing the new set of Business Capabilities they require, provide advice and help shape the strategic initiatives that are plotted on an enterprise architecture roadmap in order to drive the execution of their strategies.

The outcome of Enterprise Architecture doesn’t necessarily involve IS or IT changes, it all about the business needs.

Smart organisations have found that using ‘real’ Enterprise Architecture, instead of just a focus on IT Architecture, has helped the business plan and manage mergers & acquisitions, major e-Business transformations & consolidations, grab hold of new business opportunities and introduce new offerings faster better and cheaper.

EnterpriseArchitects.com can help your organisation use ‘real’ enterprise architecture to achieve greatness.

This post is also available at http://hub.am/c4uN

Using VPEC-T and ArchiMate

I have recently finished reading the book ‘Lost on Translation’ by Nigel Green and Carl Bate and found it a very useful and insightful. I recommend it for the shelf of any Enterprise Architect. See http://www.lithandbook.com/

The book describes the VPEC-T ‘thinking framework’ and a focus on understanding the Values, Policies, Events, Content and Trust perspectives and provides a useful language to use when speaking with the business about any strategic change.

Being keen advocate of using Archimate (http://tinyurl.com/cf3z25) for developing Enterprise Architecture models, it struck me the next step after a VPEC-T based conversation would be to write up the outcomes in an Archimate model.

So what is there in Archimate that would be useful?

The first thing I noticed is that more or less all of the Business Layer meta model concepts in ArchiMate are in scope for VPEC-T and the Application Layer and Technology Layer are not.

ArchiMate Business Layer Meta Model

That’s not to say that VPEC-T wouldn’t be useful for the application and technology layers, but it seems to be naturally focused on the Business Architecture side of things to me at the moment.

So how does VPEC-T map to ArchiMate concepts?

V = Values

The obvious first Archimate concept to use here is ‘Value‘.

ArchiMate users don’t use Value as much as they should in their models in my opinion. Using VPEC-T will correct that.

ArchiMate defines Value as that which makes some party (represented by Business Actor, Business Role) appreciate a Business Product and/or associated Business Services that they are buying, using or acquiring.

Value in this sense is also associated with a value chain (which is modelled in terms of a sequence of Business Processes and Business Activities that provide a Value).

I would also use the ArchiMate concept of Meaning.

Archimate defines Meaning as knowledge or expertise present in the representation of a Business Object, given a particular context. I would use Meaning to represent the inherent shared knowledge or value system that users have as their mental model.

P = Policies

There is no ArchiMate concept for Policy as such in the 1.0 specification but a number of EA tools that support ArchiMate do support it.

I would generally use the ArchiMate concepts of Business Function, Business Process to represent aspects of Policy. These should be used with care though, such as more in the sense of Business Rules, Guidelines, Policies, than with the normal meanings of Business Function and Business Process.

I would also use the ArchiMate concept Business Object, to represent Strategies, Goals, Objectives, Business Decisions,

In the conversation about Policies would be a focus on the Target Business [Operating] Model, in terms of what Business Product and Business Services would be sold or provided to what customer segments, i.e. Business Roles. This overlaps a bit with how one would represent a Business Model in ArchiMate which will be the subject of a future blog entry.

E = Events

The obvious Archimate concept to use here is a Business Event.

This is a key concept, and it seems especially obvious to use it in a message and service driven architectures, but it’s curious how infrequently it is actually used in most of the BPMN style models I have seen people develop.

I first started modelling with Events using IDS Scheer’s ARIS tool in 1998 and the power of an event driven approach has stayed with me ever since.

Business Events are used to trigger a value chain that results in an outcome that has Value.

Value chains are modelled using s sequence of Business Process and Business Activity and outcome of a value chain is represented with a Business Object, Business Product, Business Service associated with a Value.

Since Business Events occur via various channels, it might also be useful use the ArchiMate concept of Business Interface (representing a Channel) in your VPEC-T model, but that is a bit like solution design so is optional.

C = Content

Archimate can be used to model Content at several different levels of knowledge, information and data.

The Meaning object is used to represent knowledge, the Business Object for business information, the Data Object for data, the Representation object for the physical representation of information and the Artifact object for the physical storage of data.

In a VPEC-T model created with ArchiMate, I would mainly use the Meaning, Representation and Business Object concepts.

T= Trust

To me Trust is all about relationships, interactions and collaborations between people.

I would use the ArchiMate concept of Business Actor, representing an organisation, organisation unit or a person, and the concept of Business Role, representing the roles played by those organisations, organisation units or persons in relation to others.

For the trust relationships I would use the ArchiMate concept of Business Collaboration and Business Interaction. These don’t get used in many Archimate models but I think they are useful for representing aspects of Trust relationships.

A Business Collaboration is defined in ArchiMate as a (temporary) configuration of two or more business roles resulting in specific collective behaviour in a particular context.

A Business Interaction is defined as a unit of behaviour performed as a collaboration of two or more business roles.

I would also use the Archimate concept Contract to represent a Trust agreement (such as a Service Level Agreement) between parties.

ArchiMate concepts for VPEC-T models

Overall for doing Enterprise Architecture, I recommend using a ‘thinking framework’ such as VPEC-T first and then an Enterprise Architecture framework and modelling language such as ArchiMate second.

Enterprise Architecture Strategies

I recommend you read Chris Curran’s excellent blog entry on 16 Enterprise Architecture Strategies Learned The Hard Way

http://tinyurl.com/32hfj8s

I’ve included his list below with my views and comments following that.

1. An exhaustive enterprise level blueprint is virtually impossible to build – it’s too big and no one will buy-in

2. The best strategy blends a direction-setting enterprise blueprint and business unit and domain blueprints

3. Centralized accountability for the EA function is a predictor of success

4. A centralized team of architects is critical in driving EA standards and approaches

5. Architects must be assigned to projects as core team members (60%+ of total EA FTEs) rather than “advisors”

6. EA should be measured in 2 ways: business capabilities delivered and costs of core services

7. Measure EA as an asset – what does it cost to provide the service and what return does the business get from the business capabilities delivered?

8. Architecture leadership requires strong management, business operations and technology skills, most likely in 3 different types of people; don’t expect your chief architect to run the EA function

9. Methods and governance must be integrated into existing work processes (eg, project approvals, SDLC) rather than a new overlay

10. Enterprise Architecture is not always the best name for communicating; maybe Strategy & Planning or Enterprise Transformation is better

11. The best large companies have “business architecture” teams reporting to the business (or dual reporting to business and IT)

12. Leading companies have reference architectures in place for 90% of the technical domains

13. Your senior enterprise architects must have the right cultural skills and awareness to integrate well with upstream business partners and downstream technical users

14. High performance groups maintain consistent, formalized EA involvement in the SDLC to translate blueprints into sufficiently detailed starting architectures for each project as well as accurate cost and resource estimates

15. Mature organizations target 40% EA resource time for strategic planning and 60% on SDLC tasks, and typically err on spending more time on SDLC tasks

16. Strong credibility and trust amongst Business and IT partners is a predictor of EA success. Credibility has typically been gained via joint strategic planning efforts, one project at a time.

My Views

These are my comments on Chris’s list.

1. The enterprise architecture blueprint (i.e. the enterprise architecture content) needs to be developed in iterations, and treated as a living document/model that will never be complete. Aim for each iteration to provide value in it’s own right, to both the business and the rest of the organisation.

2. I agree that there needs to be different aspects to the business and IS strategies that address different segments of the enterprise. They shouldn’t conflict with each other though. Enterprise Architecture is all about aligning the IS strategy to the Business strategy and target business [operating] model.

3. The EA function needs an executive sponsor such as the COO that is accountable for the success of EA. I’m increasingly of the opinion that the EA function should not report to a CIO that is only focused on IT. This sends out the wrong message to the organisation as a whole. The COO should be focused on the success of the business and how it operates as a whole and not just the success of IT. In some cases success for the business may mean less IT as business capabilities in the cloud are used instead of local IT capabilities.

I’ve seen some suggestions that a new C-level post is needed to manage Strategic Change and Enterprise Architecture , that of a Chief Strategic Officer (CSO). This new role makes sense if the COO is only responsible for service delivery operations & support activities.

4. I agree – A centralized team of enterprise architects is critical in driving EA standards and approaches. There is also room for federated EA teams in large global organisations where centralised control is not feasible or even possible with local regional and country based regulatory environments.

5. Its the Solution Architects that should be assigned to projects as core team members. Enterprise Architects will be involved from a governance, compliance and design assurance perspective in quality gates/steering group meetings, and as an advisor. There are usually not that many enterprise architects and too many projects for them to be core members of every project.

Being a ‘Core’ member of a project team implies that they are managed by the project manager, whereas the relationship should be the other way around – the project manager needs to heed the advise and direction coming from the enterprise architects who have a governance sign off at the end of each project phase in project steering group meetings.

6. I agree that EA should be measured in terms of business capabilities delivered, but also in terms of value delivered. Cost of services is just one of many ways of measuring value. The value of EA is indirect though and value is only realised by solutions that deliver the business capabilities in the future many months away. To measure EA properly though means that there need to be a good record of decisions that are made by EA and the eventual outcome of these decisions in the future. This doesn’t happen much in my experience at the moment.

7. EA is a core business function in the same way that Finance Management or Sales & Marketing are core business functions. We should treat the Enterprise Architecture content as a knowledge management asset. The value is the return on knowledge (ROK) that is used in supporting decision making.

8. The EA function does need strong leadership. Doesn’t always get it though. In all the EA teams I have encountered, the Chief Enterprise Architect does also run the EA function. Within a larger EA team, there are often specific managers for the Business Architecture, Information Architecture, Application Architecture, Infrastructure Architecture aspects.

9. I partially agree. Aspects of EA Governance, Compliance and Design Assurance processes should be integrated into existing Strategic Planning, Portfolio Management, Programme and Project Management, Software Development and Service Delivery processes, but the Enterprise Architecture Development process (i.e. TOGAF ADM) will be a new overlay.

10. The name ‘Enterprise Architecture’ is all too easily confused with ‘Solution Architecture’, ‘IT Architecture’ which is a source of confusion so there are often suggestions for new names for ‘real’ Enterprise Architecture. I’ve not yet found a new name I like though it is becoming common to include Enterprise Architecture within a Strategic Change Management team.

11. Business Architecture is just one of the domains of Enterprise Architecture. All of Enterprise Architecture should be reporting to the business (i.e. the COO) rather than to IT (i.e. the CIO).

12. A Reference Architecture is a key component of the target Enterprise Architecture as a whole. In some cases these are provided by industry reference architectures.

13. I agree in general although I’d say that Enterprise Architects probably need to be much more business focused than IT focused. IT is often seen as part of the ‘problem’ and EA needs to be in alignment with the business.

14. This is more the responsibility of the Solution Architects who need to liaise with the Enterprise Architects to translate the Enterprise Building blocks into Solution Building Blocks. The Solution Architects should ideally form part of a ‘virtual’ EA team.

15. The 40% EA resource time on strategic planning and 60% on SDLC tasks mainly reflects the current overemphasis on IT Architecture being done by Enterprise Architects. I think the ideal percentages should be the other way around i.e. 60% strategic planning and 40% project related work.

16. I agree that the credibility of the Enterprise Architects and their trust relationships is critical. Building that credibility and trust starts with working closely with the business on strategic change programmes

Enterprise Architecture and Zombies

There has been much discussion about the ten Enterprise Architecture pitfalls that Gartner published at http://www.gartner.com/it/page.jsp?id=1159617

For example see  http://tinyurl.com/2wfod8q and http://tinyurl.com/3ayz6a8

In the meantime, Jane Austen and Seth Grahame-Smith have also published a great book: Pride, and Prejudice and Zombies: The Classic Regency Romance-now with Ultraviolent Zombie Mayhem!

In a spark (fit?) of imagination, the title of this blog was raised up from the depths of Mordor and just wouldn’t die…

This is a light hearted, tongue firmly in cheek,  look at Gartners 10 EA pitfalls written as a story just ripe for gore and senseless violence…

A world where Enterprise Architecture exists in an alternative universe where Zombies roam the corporate landscape. The denizens of this doomed land are the “stricken”, the “sorry stricken”, the “undead”, the “unmentionables”, or just simply “zombies”. The Zombies are those in an organisation who wittingly or unwittingly subvert the best intentions of those valiant enterprise architects envangelising about the benefits of Enterprise Architecture.

The Gartner 10 EA pitfalls are an excellent set of EA anti-patterns and avoiding them will result in a better Enterprise Architecture function within an organisation.

If you can’t avoid these pitfalls then it’ll seem as if you’re suddenly transported into the world of Zombies.

1. The Wrong Lead Architect: This is a classic and common anti pattern where the Chief Enterprise Architect turns out to be a zombie (an ineffective leader). He or she may not really understand Enterprise Architecture at all but has been put into the role by senior management because they were the only one available (dead man’s shoes?). This Dark Lord “He-Who-Must-Not-Be-Named” (ok, his name is Lord Voldemort) is making decisions with a forked tongue, for seemingly no reason whatsoever, other than to spy out opportunities and jobs for other zombies perhaps. Devoid of real interest in Enterprise Architecture he actively campaigns against its introduction.

Best thing to do is chop their head off, but as Harry Potter knows, this is easier said than done. Expect an uphill battle.

2. Insufficient Stakeholder Understanding and Support: This happens when the hordes of living dead outside the Enterprise Architecture team ignore what the EA team is doing, continually questioning the value of anything not related to their immediate problems, usually project related. This is because they are undead vampires who do not live in the real world. Get sharpening those stakes and hang up the garlic to keep them away. A huge problem occurs when the Enterprise Architecture team loses its executive sponsor. As with the volcano, Eyjafjallajökull, ash clouds of Fear Uncertainty and Doubt will start filling the air. Who is going to pay attention to the Enterprise Architects when they don’t have a sponsor?

Best thing to do is get a new sponsor as soon as possible, or start dusting off your old CV.

3. Not Engaging the Business People: Zombies don’t understand the living. They only talk to other zombies and don’t communicate much anyway. They think that Enterprise Architects are just another species of Solution Architect or Technical Architect. To overcome this make sure you get involved with the business and with real business decision making. This is not easy if the business are used to making decisions without the support and involvement of the Enterprise Architects (I’ll cover decision making in a future blog). Communications with the business units are frequently lost when the messengers are captured. Zombies that don’t like the enterprise architecture message will kill and eat the messenger. Yum.

Best thing to do is create a great communication plan and be clear about the messages, be sure to engage with the living at all times to create value and ROI and to placate the Zombies.

4. Doing Only Technical Domain-Level Architecture: Some people think that an Enterprise Architect is just another name for a Solution Architect who deals with applications used at the corporate level by all business units. These people look alive but are really undead.

Best thing to do is to clearly distinguish between the roles and responsibilities of Technical focused Solution Architects and business strategy focused Enterprise Architects. Wearing a garlic necklace should also help…

5. Doing Current-State EA First: Successful Enterprise Architecture is about the future, about strategy and governance. Zombies live in the present and worry about the current state and short term gains and don’t care about the business strategy and why they are there. They do lots of howling. Enterprise Architects are there to help the business make money in the future, faster, better cheaper.

Best thing to do is to focus on the future target business model and how to realise it.

6. The EA Group Does Most of the Architecting: The Zombies are not informed by those alive on the business side. There is consequently no buy-in for developing the Enterprise Architecture content. Zombies just want to kill people and make more zombies. They are dead anyway so don’t care about the future. The primary job of real enterprise architects is to wear silver crosses, kill zombies, vampires and werewolves.

Best thing to do is to lead the Enterprise Architecture process to develop the future architecture rather than live in an ivory tower and impose their favourite ideas.

7. Not Measuring and Not Communicating the Impact: The value of real EA is often indirect, so it won’t be obvious to the Zombies in the organisation. This then exposes the Enterprise Architecture function to the risk of failure and being beheaded. If you don’t measure what EA does then how can you manage it?

Best thing to do is to build an EA scorecard, plan the EA roadmap, concentrate on continually providing and communicating the value of EA to the living, kill zombies, sharpen your axe, and grow garlic.

8. Architecting the ‘Boxes’ Only: Enabling better business agility is frequently a key EA goal, but Zombies only care for their projects or business unit and generally won’t be rewarded for providing corporate benefits. Enterprise Architects work for the whole organisation. Where is the one true ring to help to defeat a rampaging horde of Zombies and fight the ever-present threat of a Zombie apocalypse?

One (EA) Ring to rule them all, One (EA) Ring to find them,

One (EA) Ring to bring them all and in the darkness bind them..?

Best thing to do is focus more on business strategy and the business capabilities that cut cross the business silos to provide value, polish your stakes and silver crosses and look for the one true ring.

9. Not Establishing Effective EA Governance Early: Zombies live without any governance. The quick and dirty rule, and regard the living Enterprise Architects as a troublesome, albeit deadly, nuisances. Enterprise Architects must resist the temptation to wait for more enterprise architecture content before establishing credible Enterprise Architecture governance and compliance processes.

Best thing to do is develop EA content and EA governance in parallel and constantly cry “I have a cunning plan”…

10. Not Spending Enough Time on Communications: Zombies will ignore Enterprise Architects unless they are hungry for blood. Key messages about Enterprise Architecture will not be intuitively obvious to Zombies, if at all.  Enterprise architects must constantly work to educate the living business and kill all zombies.

Best thing to do is keep sharpening the EA axe and evangelise with tailored messages to your audience.

With apologies to Harry Potter, Lord of the Rings, Black Adder and the book – ‘Pride and Prejudice with Zombies’ (http://tinyurl.com/al6gvx ) which originally inspired this blog entry…

This blog bears absolutely no relation to any organisation either living, dead or undead. Comments and Lawsuits to Harry.Potter@Azkaban.org.uk

Before all else, be armed – with a budget

Being an Enterprise Architect is a role I enjoy but I recognise the scenario described by Rik Laurens at http://www.capgemini.com/technology-blog/2010/01/enterprise_architecture_the_on.php

I think the main underlying issue is that the Enterprise Architect doesn’t, in any organisation I have engaged with, actually ever command a budget.

With money comes the power to spend it and influence others who will come to rely on that money being spent in their direction on their project etc.

Without the money weapon, an enterprise architect must rely on their powers of influence and persuasion with the C-level executives, and their governance sign off power at end of project phases and giving approval at project board meetings.

As the enterprise architecture discipline has not yet reached the tipping point where the majority of organisations realise its key importance and give respect to the Enterprise Architect, this influence and persuasion is still often overruled by JFDI thinking when the going gets tough.

Enterprise Architects do always have to continually demonstrate value and ROI, even if it is indirectly achieved by the delivery projects months away when they implement what you have defined in the EA roadmap.

However I think that Enterprise Architects do need to closely align themselves with the C-level decision makers (CIO, Business management etc.) in an organisation rather than with the project teams to achieve the necessary power and influence.

I know this sounds a bit Machiavellian, but if you are aligned too much with delivery then you’ll be seen as a [project level] solution architect and not as an [strategic] enterprise architect which is where you want to be in the first place.

It’s a fine line to walk.

Before all else, be armed [with a budget].