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.
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|
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
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
System is a functional entity formed by a group of interacting, interrelated or interdependent parts.
Artefact is an entity made by creative human work.