#entarch basics in "for dummies" style

A fragment from a forthcoming article.

Why Enterprise Architecture? – To take right decisions on evolution

Any enterprise comprises many interrelated parts. Many people work for an enterprise; they must be managed; raw materials must be supplied in time; final products must be delivered as planned; enterprise’s goals must be achieved. All of those parts must be coordinated to work together as one whole. This is no easy because of the natural complexity as there are many interrelated parts with many unknown dependencies between them. Changing of an enterprise to work better, faster and cheaper is a challenge, because the complexity of the future enterprise is unexplored yet. That complexity leads to the high risk of uncertainty in changes.

The world experience shows that architecture is the way to reduce undesired complexity of a system (please, note that any enterprise is a system). Architecture shows in a simple manner the most important parts of a system and relationships between them. The understanding of them enables the evolution of the system as one whole.

The popular example of the architecture concept is civil architecture. A customer contacts a civil architect to present to the customer a solution (in some kind of visual format, e.g. a drawing or a scale model, because the aesthetics are often very important). After approval by the customer, the civil architect works with a general contractor. Figure below shows that an architect is a person who translates a customer’s requirements into a viable plan and guides others in its execution.

Architect works with the both customer and general constructor

Architecture of a small enterprise is comparable with the architecture of a separate building; architecture of a big and medium enterprise should be compared with the urban or city planning. The latter requires thinking about the water, sewer, electricity, and transportation infrastructures between buildings or quarters of a city. An enterprise architect, like a city planner, both frames the city-wide design, and formulates plans for the development of urban and suburban areas.

Enterprise Architecture (EA) [http://www.gartner.com/it-glossary/enterprise-architecture-ea/] is a discipline for proactively and holistically leading enterprise responses to disruptive external forces. EA creates and delivers the actionable knowledge about an enterprise. This knowledge facilitates the enterprise evolution toward desired business vision and outcomes.

How does EA operate? – Facilitating changes

Does an enterprise or a plan behave like “house of cards” in case of changes? Do people endlessly discuss potential changes without coming to a logical conclusion? Do unilateral changes in one department cause problems in other departments? If yes for any of those questions then somebody should anticipate and facilitate the changes.

EA provides: 1) understanding of “operations”, i.e. daily work of the enterprise, and 2) rationale for “transformation”, i.e. changes of the enterprise. What is “transformation” today becomes “operations” tomorrow. The both are equally important and must be considered together.

EA is involved into all change-centric processes as shown in the table below.

Change-centric process	EA acts as	Added value
bottom-up, e.g. business as usual, continual improvements	a guardian of the consistency and integrity	EA estimates the effect (positive or negative) of proposed changes
top-down, e.g. strategy, transformations	a governor to take into account the complexity and impacts	EA finds leverage points (places which bring the biggest improvements)
change-execution, e.g. strategy execution or program implementation	a guide to lead to a desired outcome	EA brings agility, flexibility and transparency

EA makes the knowledge actionable in the change-centric processes. A few examples of typical use of EA will be discussed in the article in more details.

What EA uses? – Artefacts and models

Changes (as a trip to an unknown territory) should not follow the popular “go there – do not know where, bring it – do not know what”. A good trip requires proper instruments, including a map and GPS navigator. EA provides all of them.

EA identifies and describes various constituent parts of an enterprise-as-a-system. Those parts are called artefacts. Typical artefacts are: operational objects, goals, business processes, roles, rules, locations, documents, tools, etc. EA links them in various models (e.g. organisational structure connects organisational units, roles, and people). Models formalise as knowledge the relationships between artefacts. Thus models make this knowledge actionable.

EA establishes rules for changing those artefacts and models as architectural principles, templates, techniques, patterns, and standards. At the same time, EA does not own those artefacts and models. They are owned by various people from the enterprise – stakeholders, CEO, COO, CIO, business process owners, line managers, etc. EA contributes to human capacity by helping those people to understand, create, arrange, interrelate, use, and evolve their artefacts and models.

Variations of architects

Basic type of architect	Primary customer	Plan	Executors of the plan	Comments
Solution architect	Project owner	Architecture of a solution	A project team	Also known as “architecture owner” in agile projects
IT Infrastructure architect	CIO + EA	Infrastructure improvement / modernization / transformation	Infrastructure unit of the IT department	This plan is usually spread over several projects
IT Application architect	CIO + EA	IT Application portfolio improvement / modernization / transformation	IT demand, IT supply (DEV and OPS) units of the IT department	This plan is usually spread over several projects which blend business and IT improvements
Information & data architect	CIO + EA	Information & data improvement / modernization / transformation	Information (business) and data (IT) units	This plan is usually spread over several projects
Business architect	Ideally: COO + EA; Possible: (depending on the maturity of organisation) CIO+EA	Business processes, organisation improvement / modernisation; strategy execution	Business departments and IT demand units	This plan is usually spread over several projects
Enterprise architect	Ideally: CEO; Possible: (depending on the maturity of organisation) CIO, COO	Strategy execution	Divers teams	See "Evolution of the EA function" at http://improving-bpm-systems.blogspot.ch/2014/03/enterprise-patterns-aga.html

Some combinations:
Enterprise solutions architect – solution architect for enterprise-wide solutions
NNN solution architect – solution architect in the NNN domain, e.g. SharePoint

Architect vs project manager

Architect defines a plan.
Project manager executes the plan with the guidance of the architect (for example, a general constructor can’t change the building’s plan without approval of its architect).

A few definitions

Architecture is a fundamental orderliness (embodied in its components, their relationships to each other and the environment), and the principles governing the design, implementation and evolution, of a system.

System is a functional entity formed by a group of interacting, interrelated or interdependent parts.

Artefact is an entity made by creative human work.

Thanks,
AS