EA today

"Wow. Such a comprehensive overview of the practical, real-world VALUE that EA's provide."

Enterprise architects do not "architect the enterprise". They architect business roles and processes where, and in so far as, they create and use digital data. For explanation, read this article.

"The Information Age" took off in the 1960s, when governments and businesses started to use information technology. As people recognized opportunities to “digitize” more and more business activities, IT departments took on the role formerly played by Operational Research departments.

Enterprise Architecture (EA) emerged in the 1980s as a name for cross-organizational analysis and design of how business operations, business roles and processes, create and use digitisable business data.

• "As an enterprise architect, I architect how business roles and processes create and use digitized data, taking a cross-enterprise and strategic view of where to standardize and integrate business activities and business data, and where to innnovate."

EA regards the enterprise as a system in which regular activities are enabled and integrated by information flows. Of course, an enterprise is more than that. It is a social entity in which every human actor has their own motivations, and some activities and information exchanges are ad hoc. So there are parts of the enterprise that EA does not reach.

The motivations for an EA change initiatives, are:

• part strategic and long term (business mission, vision, drivers, goals),
• part tactical (line of business needs), and
• part just "tidy up the mess".

EA domains and levels

The focus of EA is very much on business operations that create and use business data. EA has never been about the design of buildings, vehicles, production lines, shelving systems or other material structures. Nor is it about the management, team structures or sociology of a business.

Four BDAT architecture domains

For any given change initiative, the architectural design sequence has always been

1. Business roles and processes
2. Data created and used by 1
3. Applications needed to capture, analyse and provide 2
4. Technology infrastructure needed to run 3.

Note that some aspects of business system design, such as security, span all the BDAT domains.

Three or four architect levels

In a large enterprise, architects work at several levels.

• Enterprise architects - at an enterprise-wide and/or segment level
• Solution architects -at a project level
• Software and other specialist architects.

Enteprise architects take the broadest and longest term view of business activities supported by information systems. Other architects take narrower and shorter term views.

Some like to draw an analogy between EA and building architecture or city architecture. People often turn to analogies when they can't readily explain something. Since this can lead people down a wrong or impractical path, I think it safer to explain EA without reference to concrete buildings or civil engineering.

Architecture documentation

The only architecture we can meaningfully discuss is one we can see - either directly in reality, or in documentation that we share. Since it is impossible to observe more than a tiny fragment of a business directly, we have to document the BDAT domains of enterprise architecture.

A?solution architecture?represents, at an outline level

• the structure and behavior of a system, or related systems,
• designed in response to a given problem or requirement, and
• usually implemented via a project.

EA is about the big picture, taking a high-level, wide, strategic and cross-organizational view of business activity systems, and the IT they depend on. Your?enterprise architecture?is whatever you can document by way of

• a business function (or capability) hierarchy
• end-to-end business process (or value stream) models
• application portfolio
• other documentation, such as a data glossary

with mappings between them.

Solution architects work on a subset of the enterprise architecture, but also at a lower level of design than can be governed at an organization-wide level.

The EA reporting line

The diagram above shows how TOGAF positions EA in relation to other business and IT functions. In some organizations, there is an “Enterprise Architect” with that title. In others, the equivalent person is the manager of a team of architects, which might be called “Strategy and Architecture” or the like.

Reporting structures include

• EA reports to CIO, who reports to CEO
• EA reports to CIO, who reports to CFO or COO, who reports to a CEO.?

Some propose EA should sit outside of IT, perhaps reporting directly to a COO. However, since most "Operational Research" departments were absorbed into IT departments, there is no longer an obvious cross-organizational home for EA outside of the IT function. And if you create one, it will be dependent on people in the IT function, or with their knowledge and skills.

What do EAs do?

Perm these words as you choose

• "Strategic
• Business, Application or Technology Portfolio
• Analysis, Architecture, Blueprinting, Innovation, Management, Modeling, Planning, Rationalisation or Roadmapping,
• with a view to efficient and effective Digitisation or Business-IT alignment."

In short, Strategic Business and IT Planning?

Suppose the CEO is not clear what the EA does, and they meet in an elevator.

• CEO: What are you responsible for?
• EA: Cross-organizational Strategic Business and IT Planning.
• CEO: What do you think my business directors (CxOs) are responsible for? Take some time out, and come back with a better answer, dropping the word strategy.

The EA does some research and draws the following conclusions about what EA is and is not.

EA is not

EAs are not business directors

Business directors define and maintain

• Business mission
• Business vision, and in response to business drivers
• Business goals/objectives, top-level plans

This may involve analyzing performance, predicting demand, and directing changes to any of the following.

• Constitution: mergers, acquisitions and divestments, opening/closing outlets.
• Market: industry domain/sector/segment, customers and suppliers.
• Products and services: sales and service channels, prices.
• Relationships: partners, in-sourcing and out-sourcing of operations.
• Resources: people, wages, machines, locations/buildings and other physical asset types.
• Management structure: hiring and firing CxOs and restructuring the organization.

EA is not about everything

EA is about business roles and processes that create or use recorded data.

• In a bank or government agency, that may be most of the business.
• In a manufacturing, engineering, agriculture, education, healthcare or entertainment businesses, there is more material processing or personal interaction.

Even in a bank, EAs do not design material products, buildings, or HVAC systems, define employee terms and conditions, or design shareholder meetings.

EA is not all about transforming an enterprise

EA is not often about the design and planning of a root and branch "enterprise transformation" (of the kind McKinsey report fail 70% of the time). And to change everything all at once is likely to disastrously disruptive. So, EAs prioritize by asking sponsors and stakeholders where they see the biggest pains today, and gains to be made tommorow, in business operations.

An EA cycle of the kind in TOGAF's ADM is prompted by a particular "request for architecture work", a request for some substantial change. EAs design and plan earlier transition states in more detail than later ones, and allow that the requirements and destination may change.

To align two silos you don't need to understand the whole enterprise, you only need to understand the two silos well enough to ensure solution architects in them co-ordinate their efforts. The "doctrine of marginal gains" applies.

EA is not Organization Design

Conventionally, an EA function tries to distance itself from Organization Design, by relating activities, systems and other resources of interest to a logical Function or Capability hierarchy rather than today's management structure.

Where the desired business change does involve changing the management structure and roles of people in it, that is overseen or even directed by a "Business Change Management" function that works in partnership with the EA function.

Other lessons from history

EA is not a journey with a destination, it is an ongoing effort to minimize costs and risks, wastes and disintegrities (caused by letting a thousand flowers bloom) and to prioritize changes/innovations.

Nobody can know everything. The EA team or function is a collective who cooperate to coordinate systems they know about and work on. Team members incrementally get enough of an enterprise-wide view to help them minimize costs and risks, wastes and disintegrities, and to prioritize changes/innovations.

The same elevator, a week later

CEO: Hello again! Have you clarified your role?

EA: Yes. My team supports and enables your business?mission and vision by

• increasing the effectiveness and efficiency of business operations that create and use digitisable data
• enhancing the quality of the information operations depend on
• integrating and standardizing business processes
• advising you on innovative digitization possibilities.
• governing solution architects to keep them on the right track.

CEO: Better. Please report to me next month on your progress.

Note: EA team members are not accountable for business and IT strategies. Rather, they inform them, and may steer them. In RACI terms, they share some R but are not A.

With or without a business strategy, there is a need for architects, with a long-term and cross-organizational perspective, to have oversight of IT-related projects and product developments, and to identify and mitigate technical risks - including the risks of letting a thousand flowers bloom - under the direction of specialists wanting to extend their?CV.

The focus on business system planning

Enterprise and solution architects may stimulate and contribute to business planning. Especially in information processing businesses like banks, insurance companies, government agencies and internet-based businesses. Not so much in businesses that manufacture material things or provide face-to-face services.

Where the entire business is about processing digitized data, the CEO and the EA must be in lock step. Still, an EA team doesn't architect everything that flows from the mission, vision, drivers and goals of a business.

Consider a university. The EA function is not responsible for the design and delivery of the prospectus, the courses, research projects, lectures, employee terms and conditions, buildings and furnishing of them, slide projectors and HVAC systems. On the other hand, when and where those things create or require business data, they may be of interest to EA.

EA has always focused on business activity systems can be be at least partly digitized. It should shape and steer changes that relate to extending, improving or securing such systems. And it should be engaged in the definition of any digitization initiative. Other kinds of business change or innovation may be led by others - directors, business managers, mechanical engineers, sociologists, etc.

Enterprise and solution architects often work hand-in-hand with:

• a programme/project management office (PMO),
• a business change function (when human roles are significantly impacted) and?
• business operations management and IT services management functions.

Related articles

This is one of two related articles

• Positioning EA today
• Architect roles

Can you readily measure the impact of EA? Not easily. Years ago, I posted a slide show on?measuring EA.?

Read Other EA challenges for populating your strategy and architecture team, governance of solution architects by enterprise architects, and?“Guerilla EA”.

For more on architecture domains you might try this?Government of Canada EA Framework.