Linkedin: Towards applied enterprise architecture

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=1426597&discussionID=12055573&sik=1263588623939&trk=ug_qa_q&goback=.ana_1426597_1263588623939_3_1" />


This is clause 13.5 from my book "Improving enterprise business process management systems" www.samarin.biz/book

The classic EA way is to document the existing (so-called “AS IS”) state of an enterprise to a very high level of detail, with many views, and in accordance with different existing EA frameworks. A bulky document with a lot of artefacts (goals, objectives, policies, standards, processes, data, KPIs, events, services, etc.) and some relationships between them certainly can impress the customer.
But such a document is just the beginning. The customer’s typical expectation is that this document will help the customer to take informed decisions for different business scenarios. The following typical scenarios are quoted from Google “The enterprise architecture network” group: merger, changing of a functional unit’s structure, survival in heavy competition, cost cutting, modernisation of legacy applications, outsourcing the whole functional unit or just its IT environment, portfolio rationalisation, etc.
So far, EA cannot provide precise guidance for these scenarios, because the future (so-called “TO BE”) states in these scenarios are not known precisely in terms of artefacts, and thus cannot be compared with the current “AS IS” state to a good level of accuracy, although a good description of the “AS IS” state may give some hints. So, in the absence of a good global direction, the business takes its favourite approach via small incremental modifications based on their implicit logic thus permanently changing the “AS IS” state.
We think that the gap is in the absence of explicit knowledge about how the “enterprise genotype” (a full nomenclature of enterprise artefacts) defines the “enterprise phenotype” (a set of observable characteristics such as performance). Considering that EA does a great job in describing the “enterprise genotype” and there are many techniques to evaluate the “enterprise phenotype”, then the BPM discipline with its executable models of relationships between artefacts can form the bridge (an enterprise executable model) between the “enterprise genotype” and the “enterprise phenotype”.
Of course, such an enterprise executable model may change over time and even be built with different best practices. But if both the “AS IS” and the “TO BE” states have enterprise executable models which are built on the same principles, then one can

1. compare and evaluate different “TO BE” states to select the desired one, and
2. produce better and more systematic transformations from one enterprise executable model to another to reach the desired “TO BE” state faster.

The ingredients of an enterprise executable model are the following.

• Choose a proven way to conduct the business, e.g. a process- and service-centric enterprise will have “AS IS” and “TO BE” states which can be compared.
• Establish a comprehensive inventory of all enterprise artefacts, including those from business (roles, processes, events, etc.), information systems (data, services, etc.) and technology (servers, etc.), as normal housekeeping practice.
• Explicitly model relationships between these artefacts (e.g. to fulfil the business process Z we need the information systems X1 and Y2) to reveal all hidden relationships and to structure them. This can also help an enterprise to estimate better certain characteristics such as service availability and the cost of particular operations.
• Make all models executable. The best example of an executable model is a business process model. This is an aggregation of events, human and automated activities, roles, objects, rules, audits, etc. Again, this is the essence of BPM – “what you model is what you execute”.
• Make all artefacts digital, external and virtual so that they can be used in executable models and are easy to evolve.

We have observed that most of the items in this list are usually in place in many enterprises, but the items are often treated separately. For example, the business offers services and uses processes which are described only in the Quality Management System (QMS documentation. The inventory of artefacts and their relationships are defined by an EA tool. Everything that is executable is kept by the IT unit.
There is nothing fundamentally unusual in this approach – it’s just a question of making previously separate things work together. Of course, this is not a mechanical but a holistic aggregation.
This synergy provides very important information for decision making – how many resources are consumed by a particular artefact and what is the contribution of each artefact to the enterprise’s objectives? The information that application X is used in process. A is useful, but it is even more valuable to know that application X is supported by N persons, but was used in only a few instances of process A, and most of these were cancelled without any financial outcome.
Now let us see how this approach can help enterprises with some of the scenarios mentioned previously for business transformation. In any merger, one of the problems will be the intermixing of two previously independent enterprises, e.g. the services provided by one enterprise are to be embedded into the processes executed by the other enterprise. By analysing the gaps between the service interfaces and process definitions, one can properly estimate the cost of such intermixing.
For any cost optimisation scenarios, the real contribution of each artefact to the enterprise performance should be a clue. In portfolio rationalisation, the economic effect of each project is easy to evaluate because the projects deal with schematically similar and transparent process- and service-based business. Moreover, it is possible to anticipate that one project improves artefacts which are to be reused in another project.
Any enterprise has its own architecture, but is this architecture fit to face the challenges that the enterprise will encounter? And if the top management accepts to improve the architecture of an enterprise, who will be chosen to manage this job? Any candidate should have a wide range of skills to be able to play different roles, and should demonstrate comprehensive knowledge of the business, information systems and IT.
Thanks,
AS