Place of #entarch in an enterprise organisational chart

Based on the Linkedin discussion Should an Enterprise Architecture role report to the CEO?.

It depends (as usual). Place of EA should depend on the maturity of the whole organisation.

• Low level - EA is under CIO 
• Middle level - EA is under COO 
• High level - EA is under CEO 
• etc. 

Of course, there are extremes like an CIO saying: "Architecture? We don't need such a function. Everyone will do architecture".

Thanks,
AS

#entarch was mentioned in Davos at WEF

From  http://www3.weforum.org/docs/EU11/WEF_EU11_FutureofGovernment_Report.pdf

An Enterprise Architectural Approach. e-Government may be thought of as a complex socio-economic and
human-machine system, which has begun to be explored and developed in recent years with the use of the Enterprise Architecture (EA) methodology. This approach encompasses a generalized representation of the subject domain structure and the subsequent formation and use of the principles and guidelines that define the system architecture development management over time.

One of the important advantages of this architectural method is the availability of tools that allow a government (or any organization) to synchronize a complex system development strategy with opportunities carried by ICT.

Thanks,
AS

An example of #entarch contributing to a business strategy

"The aim of this Brief is to outline how the coherent use of several existing information technologies can significantly accelerate the achievement of the vision stated in the Bank’s Long-Term Strategy (LTS)."

UNIQUE OPPORTUNITY FOR AFRICA: ARCHITECTING THE SYNERGY BETWEEN EXISTING INFORMATION TECHNOLOGIES

Thanks,
AS

Enterprise pattern: SITO, extended

Comments to SITO enterprise pattern (see the updated version of it at http://improving-bpm-systems.blogspot.com/2011/10/enterprise-pattern-structuring-it.html ) were that it is too classic. Sure, structuring is the first step to establish the balance between functions and projects.

Next step is how to preserve, enrich and re-use the technical/business knowledge and experience gained in each project. A possible way is to create competence forums which are oriented to deliver business-generic services (or "needs" as they mentioned in http://improving-bpm-systems.blogspot.com/2011/09/writing-it-strategy.html ). Usually, such services are based on several IT-generic services which are mastered in different IT functions.

How those competence forums to be managed to avoid over complication and conflicts of responsibilities? Competence forum is led by the CIO with the help from an informal leader from the participants. For example, the CIO chaired a few initial meetings and then delegates the routine work to the informal leader.

Next step, the IT governance, was already covered in http://improving-bpm-systems.blogspot.com/2011/01/relationships-between-ea-and-pmo.html . Just a small addition to that post:

• EA (or EITA) defines/monitors WHAT should be done (technical coordination of the enterprise IT environment).
• PMO defines/monitors HOW it should be done (administrative coordination of changes in the enterprise IT environment).

Both EA and PMO are top-down and they are supported by bottom-up ITIL (http://improving-bpm-systems.blogspot.com/2011/01/relationship-between-ea-pmo-sdlc.html ). 

Thanks,
AS

Relationship between EA, PMO, an SDLC methodology and ITIL

Continue of the post “Relationships between EA and PMO”.

For the moment, I don’t discuss the “local” SDLC methodology. It is considered that it translates (as a project) a request for a business solution into a set of interdependent services. Some of those services are new; some of those services are new versions of existing services. The main steps of such a translation are:

• Architect a solution as a set of services (BPM, SOA, etc. is are used for quick prototyping to understand WHY and WHAT for each service as well as the effect on the whole enterprise environment)
• Design each service (supply HOW for that service – buy, build, rent, outsource)
• Deploy each service (of course, provide the ruthless monitoring for each service before deployment)

So, it is necessary to guarantee that newly created services or versions of services will be the good ITIL citizens. For this reason, many of ITIL processes have to be “invoked” during projects as shown in figure below.

Thanks,
AS

Relationships between EA and PMO

In my current position at a chief enterprise architect I have to provide a clear guidance how EA, PMO, PMBOK, BPM, SOA, ECM, SDLC, CMMI, ITIL, etc. should work together. This post is about EA and PMO.

EA is a management tool to help the enterprise to realise its vision by provisioning guidance and practical help for the design and evolution of the Bank via the enterprise models as well as with a coherent and proven set of principles, recommendations, and practices for working with those models.

EA has the three explicit parts: model, management and governance. Model is a set of enterprise artefacts and relationships between them. The governance part is used for the strategic improvements and self-tuning of the enterprise environment. The governance defines the model for a target environment and the means (a road map presented to the business as the strategy) to implement necessary changes from the baseline model to the target model. The management part supervises those changes which are carried out in different internal projects. The latter are controlled by PMO.

Thanks,
AS

Linkedin: This is what is killing Enterprise Architecture…

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=1523&discussionID=13538757&goback=.anh_1523" />

If I look at an enterprise as a complex, dynamic and self-evolving socio-technical system of systems then I can say that “the set of descriptive representations that are required in order to create” an enterprise is necessary, but not sufficient.

I consider the following list of “missing” parts of EA

1. In addition to explicit “descriptive representations” is it necessary to have explicit “prescriptions” how to improve and evolve a particular enterprise – some kind of a set of architectural principles. Rationale – high level of changes, many people are involved.
2. Relationships between enterprise artefacts have to be explicitly expressed. For example, a process is a complex relationship between data, documents, roles, rules, services, processes, KPIs, etc. Rationale – systems thinking.
3. All descriptions have to be actionable – the same description should be used to a) coordinate the daily work, b) take a management decision, c) implement a new improvement. Rationale – support cost for a few duplicating descriptions (first thing to kill in case of lack of resources).
4. EA is about the whole enterprise, so everyone in the enterprise is a stakeholder of EA and everyone in the enterprise is the customer for an enterprise architect. So, if many our customers are “killers” of our work then may be something wrong with us? Rationale – a lesson from developing socio-technical systems: “how you do something is sometimes more important than what you do”.
5. Understanding that a system for a person is a module for another. Rationale – nested/recursive/fractal character of enterprises.
6. And all those parts should be aligned to work together for a particular enterprise.

Please feel free to extend this list.

Thanks,
AS

Linking concepts and expressions used in Enterprise Architecture (EA)

The purpose of this article is an attempt to link some concepts and expressions used in Enterprise Architecture (EA). Some material from discussions at LinkedIn was used for this post.

First, the famous columns from Zachman framework

WHAT – assets (physical and electronic ones, e.g. business objects)

WHO – roles (e.g. people, organizations, governing bodies, other actors)

WHERE – places (physical and virtual ones)

HOW – functions (actions of making some assets from other assets, adding value to assets, etc.)

WHEN – events (temporal, systematic, spontaneous, external, internal)

WHY – reasons (e.g. motivation, rules, internal and external constrains including desired performance, principles)

maybe to add also
WITH WHAT RESULTS – KPIs (derived from audit trails as actual performance)

Next, two overused terms

Service is an explicitly-defined and operationally-independent unit of functionality. Service is a black box to produce some assets. Service is an external perspective of a function. One or many distinct functions can be fulfilled by a service.

Process is an explicitly-defined coordination of services to create a particular result. Process is a white box to produce some assets. Process is an internal perspective of a function. Process is a composite from many different artefacts (roles, rules, assets, functions, etc.).

Remark: Services and processes can be considered to be intimately related since in real terms

• all processes are services,
• some functions of a service can be implemented as a process, and
• a process includes services in its implementation.

So, at an enterprise we may have many elementary nano-services which are organised into a mega-service, i.e. the whole enterprise.

And a very controversial term at the end

Capability is the possession of characteristics required to produce a particular outcome. The latter is a pair “right things” (assets) and “done well” (performance, reliability, etc.) as the result of work of a function (regardless how this function is implemented). So, a capability combines functional and non-functional characteristics (timeliness of outcome, data accuracy, quality of result, efficiency, effectiveness, impact on stakeholders, SLA, SLE, etc.) of a function. Important to note that a capability describes some kind of expected characteristics of a function, but not actual results demonstrated in particular cases. This is similar to normal cars are which capable to do 200 km/h, but they rarely go faster than 130 km/h.

Are capabilities the building blocks (easy to move, reorganize, outsource, etc.) of business? Only if a corresponding function is exactly a service (so, the function is operationally-independent and it can be improved without causing any negative effects).

Functional characteristics are known from a function itself. Non-functional characteristics can be obtain from specifications (as defined in a contract or a description), by measurements (performance testing) or by design. The latter option means that a function (a part of the whole service) can be implemented as a process for which performance characteristics can be obtained from the performance simulation of the process template. In some cases, obtaining non-functional characteristics by design is the most practical way.

A possible scenario

Stakeholders:
OK tell us about your brilliant idea.

Future CEO:
We plan to provide to the market a product WHAT1 manufactured from WHAT0 with the performance WHY1. This will be fullfiled by function HOW1 implemented via service ServiceHOW1

WHAT1 = ServiceHOW1(WHAT0) // Magic happens here

Stakeholders:
Sounds good. But, is ServiceHOW1 capable to operate as required by WHY1?

Business architect:
The desired performance of ServiceHOW1 is guaranteed by its implementation via ProcessHOW1. In some way, WHAT1 is decomposed into a set of WHAT2x. WHY1 is decomposed in a set of WHY2x. All together will be coordinated by this process.
ProcessHOW1 = {coordination1, HOW2*, WHAT2*, WHY2*, WHO2*, WHERE2*,... }

Stakeholders:
Please continue until black boxes become too trivial so they can be bought, rented, outsourced and easily implemented.

What do you think?
Thanks,
AS

Linkedin: Top three Enterprise Architecture challenges?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=36781&discussionID=9394300" />

1) Move from vendor/group/institute-centric EA to customer-centric EA.

2) Advance from just being DNA or “enterprise genotype” (a full nomenclature of enterprise artefacts) to provide a formal link with “enterprise phenotype” (a set of observable characteristics such as performance).

3) Develop a commonly-agreed reference model.

Thanks,
AS

Linkedin: What does mean the term 'Business Architecture' today and what it should mean tomorrow?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=84758&discussionID=6110389&sik=1250500606590&trk=ug_qa_q&goback=%2Eanh_84758%2Eana_84758_1250500606590_3_1" />


I would start from the context and a few definitions. (I use below some of my definitions from http://www.samarin.biz/terminology )

In the broadest sense and as already mentioned, an architect is a person who translates a customer’s requirements into a viable plan and guides others in its execution.

In the case of enterprise, the "roles" from this definition can filled in the following way:
“customer” = top management, senior executives
“wishes, dreams and expectations” = creating a new company, merger, changing of unit’s internal structure, survival in heavy competition, cost cutting, modernisation of legacy applications, outsourcing the whole unit or just its IT environment, portfolio rationalization, etc.
“others” = the whole enterprise

An enterprise can be, for example, a business unit or department, an entire corporation, a government agency or a collection of businesses joined together in a partnership. An enterprise can be considered as a system whose parts are people, processes, information and technology. In general it is a complex and dynamic system of systems.

I use a term “enterprise business system” for the top level view of an enterprise as a system for conducting the business. This top level view may concentrate on how the business is structured, what it does and what it needs to do to meet its goals. The issues of greatest importance for enterprise business systems are the following:
• the core end-to-end business processes (also known as value streams);
• the governance structures;
• the core business information (semantics);
• the communication with the core business partners.

Architecture of a system is, in some sense, the main tool to work with the system. Architecture comprises two inseparable parts: descriptive (nomenclatures of artefacts, relationships, etc.) and prescriptive (rules on how to evolve this system). Both of them may be implicit or explicit or somewhere in between. Both of them are used together in “what if” analysis of different changes.

So, “architecture of an enterprise business system” or “business architecture” -- coherent and proven set of principles, recommendations, practices, and tools which provides guidance and practical help for the design and evolution of enterprise business system to achieve enterprise vision and strategy.

Thanks,
AS

Blog: Is Enterprise Architecture sociotechnical systems (STS) design ?

<discussion ref="http://beyondinformation.blogspot.com/2009/07/is-enterprise-architecture-social.html" />

As any modern enterprise is a socio-technical system then any enterprise-wide activity, e.g. EA, enterprise BPM, should explain to all stakeholders of this activity how this activity will address their concerns and improve their work. For detail, please, see the second part (from slide 23) of http://www.slideshare.net/samarin/architecting-enterprise-bpm-systems-for-optimal-agility-presentation


Thanks,
AS

The Forrester blog for EA professionals: Principles don't matter

<discussion ref="http://blogs.forrester.com/ea/2009/05/principles-dont-matter.html" />


I always recommend to add my favourite principle:

"You may break any principle provided that you master it"

Sure that any of principle is just an advice. It is quite normal to break any them if you know the reasons which are behind a particular principle and how they do match to a particular situation. For example, in the chess game is it recommended to novices do not exchange the queen vs. a pawn, but such an exchange can be a part of a combination which leads to the checkmate.

Thanks,
AS

The Tech Evangelist blog: The Relationship Between SOA, BPM & EA

<discussion ref="http://jpmorgenthal.com/morgenthal/index.php?entry=entry090522-213329" />


Interesting post, because understanding of relationships between elements (i.e. BPM, SOA, and EA) of a system is the way to understand these elements. A few comments.

I define BPM and SOA slightly different.
BPM, actually, covers three different concepts (see Should we consider third (forgotten) BPM?):
1) BPM as a discipline or methodology
2) BPM as some software, i.e. BPM suite
3) BPM as a system for managing of business processes with an enterprise

SOA is architectural approach for constructing software-intensive systems from a set of universally interconnected and interdependent services (service is an operationally independent unit of functionality)

Relationship between BPM and SOA :
BPM discipline, by revealing the artefacts and the relationships between them, provides the necessary context (e.g. granularity) for the definition of services.
SOA provides recommendations for the implementation, execution and governance of services.

To build a good enterprise BPM-system, others (BPM discipline, BPM suite, and SOA) are necessary, but not sufficient. A good architecture is mandatory.

BPM and SOA are more than views of enterprise architecture (EA). Classic EA gives only "enterprise genotype” (a full nomenclature of enterprise artefacts) and it does not provide “enterprise phenotype” (a set of observable characteristics such as performance). A possible way to achieve a formal link between "enterprise genotype” and “enterprise phenotype” can be enhancing of EA by BPM and SOA which are able to define "enterprise executable description”.

Top Down or Bottom Up ? I recommend pinball style (see "Linkedin: Top Down or Bottom Up ?")

Thanks,
AS

Linkedin: What 'peri-operative checklists' could and should we use in EA/BA?

<question group="BP group">

Research by World Health Organization ("New England Journal of Medicine" 2009 Jan 14, doi:10.1056/NEJMsa0810119 ) shows that use of a simple 19-point peri-operative checklist - checks immediately prior to and during surgical operations - reduced complications by one-third (from 11% to 7%) and deaths by 40% (1.5% to 0.7%). The results, from a large statistical base (c.7500 cases) were much the same in rich and poor countries. The English-language version of the checklist is at www.who.int/patientsafety/safesurgery/en . What equivalent 'peri-operative' checklists could we develop for enterprise-architecture and business-architecture? What results could we achieve with such checklists? And how would we verify their value? (Discussion posted to both The Enterprise Architecture Network group and Business Architecture Community group.)

</question>


My client has a checklist for the technical architecture -- each IT project should present such a list before the technical evaluation (which is before the financial evaluation of the project). The main reason is to prevent surprises in deployment and maintenance (e.g. high disponibility requires a special configuration of Oracle). Typical topics are:
• Architecture générale
• Support et maintenance
• Exploitation
• Architecture poste de travail
• Middleware
• Architecture base de données
• Services business intelligence
• Services éditiques
• Services Génie Logiciel
• Services gestion documentaire
• Services sécurité
• Métier
• Interopérabilité
• Réseau

As there are some dependencies between items of this checklist, we provide a simple configurator which uses many (business and technical) questions and some rules to derive the actual checklist.

Thanks,
AS

Linkedin: What do you (your company or clients) use Enterprise Architecture for?

<question group="The Enterprise Architecture Network">

What do you (your company or clients) use Enterprise Architecture for? Think of Enterprise Architecture in action (from experience), how it is used and for what.
I know it sounds like a strange question, but I want you to think - what is EA really used for... to understand the enterprise form all perspectives? to use as a tool to explore and discover opportunities for change? to facilitate change?...or to guide change? (there is a difference between these two) to define transformation? to empower project/program contributors and stakeholders? to manage projects? to facilitate managerial decision making? to manage growth? to facilitate strategic decision making? to enable cross-functional/domain integration? to present how IT domains relate to each other? to drive IT strategy? etc.....I'm sure there are lots more uses, especially beyond an IT centric approach Not looking for explanations of, or references to TOGAF, Zachman etc. Please make this practical...for what (and how) is Enterprise Architecture used in your experience?

</question>


A client just created a EA unit which provides the following services:

1. Validate a solution's architecture at different stages of the project
- EA unit requires use of approved architectural components for the technical part of a solution
- EA unit recommends a few prototyping environments (one of them is base on the BPM discipline and a BPM suite) for the business part of a solution

2. Guarantee coherence of architectural components

3. Optimisation of architectures for future needs (e.g. having solutions more adaptable)

4. Internal consulting


We recommended this client the following:

Definition: The EA unit is a group of like-thinking minds responsible for proactive evolution of the architecture of the enterprise.

Mission statement: The mission of the EA unit is to provide guidance and practical help for the design and evolution of IT and business to achieve the enterprise vision and strategy.

Objectives: The EA unit (together with a forum of architects) develops and maintains a comprehensive set of recommendations, models, patterns, examples, tools and training materials.

Linkedin: I NEED INPUT ON A WHITE PAPER. CAN YOU PLEASE REVIEW THE LINKED ARTICLE?

<question group="Business Process Improvement">
I NEED INPUT ON A WHITE PAPER. CAN YOU PLEASE REVIEW THE LINKED ARTICLE?
.

www.OnTheSystem.com/everything

</question>

I like the idea of a simple theory which will help us to improve enterprises.

Some of my ideas from http://www.improving-bpm-systems.com/pubs/AS-AW08-keynote.pdf

An enterprise BPM system is a dynamic set of artefacts (or building blocks?)

Artefacts are interconnected and interdependent

We have to anticipate potential changes: policies, priorities, compliance, technology, etc.

Implementation of such changes necessitates the evolution of some artefacts and the relationships between them

It must be easy to modify all artefacts and relationships without causing any negative effects

Principles:
- All artefacts must be evolved to become digital, external and virtual
- All artefacts must be versionable throughout their lifecycle
- All relationships between these artefacts are modelled explicitly
- All models are made to be executable

Thanks,
AS

LinkedIn: What is the difference between Enterprise Architecture, Business Architecture and the various other "X Architecture" names, interpretations

<question group="Business Architecture Community">

What is the difference between Enterprise Architecture, Business Architecture and the various other "X Architecture" names, interpretations and approaches?
Q1
Is there a difference or is it just semantics, causing confusion because of different naming conventions and promotion of individual view?

I have personally used "Business Ecosystem Architecture" and "Symbiotic Architecture" to define through naming a difference in my own approach, always with a very heavy emphasis on it being a business (executive) driven requirement.

Following the above...
Q2
Should Business Architecture refer to:
- Business strategy dimension for EA
- Business processes that aligns with EA (TOGAF)
- Integrated operational ecosystem model
- Whole-of-Enterprise
- Symbiotic relationship design
- Your suggestion here…

</question>



From my definitions...

enterprise architecture, noun
coherent and proven set of principles, recommendations, rules, practices, and tools which provides guidance and practical help for the design and evolution of IT and business to achieve enterprise vision and strategy

Remark 1: Examples of business vision and strategy are a higher level of maturity, a greater agility, better collaboration, merging, cost cutting, modernisation of legacy applications, outsourcing of a business unit, etc.

Remark 2: Some parts of enterprise architecture are dedicated to different stakeholders.

Remark 3: To guarantee the desired outcome, enterprise architecture needs to be as good as applied science.

enterprise business system, noun

top level view of an enterprise as a system for conducting the business

Remark 1: This top level view may concentrate on how the business is structured, what it does and what it needs to do to meet its goals.

Remark 2: The issues of greatest importance for enterprise business systems are the following:
• the core end-to-end business processes (also known as value streams);
• the governance structures;
• the core business information (semantics);
• the communication with the core business partners.

business architecture, noun
that part of enterprise architecture concentrating on the conceptualisation and evolution of the form and structure of the enterprise business system


Thanks,
AS