Enterprise
and Solution Architecture Roles: things to know
Copyright
Graham Berrisford. One of many articles at http://avancier.website.
Last updated 14/05/2021 20:14
Reading on-line? Shrink the document display width for
easier reading.
This article positions enterprise architecture in relation to business planning and to solution architecture. It outlines both the historical context for and the reality of modern architect job descriptions. In the recent years it has been downloaded from http://avancier.website getting on for 20,000 times, and is pre-course reading for some of our architect training classes.
VE “Thanks for sharing.” SW “This is good reading. Thank you
for sharing.” TRB “Good read.” SG “Very much insightful. Thanks a
ton.”
Contents
Enterprise and solution architect roles
Appendix 1: The emergence of architecture frameworks
Appendix 2: What architects don’t do
"The Information Age" is the name given to the shift, starting in the 1960s, from the industries established by the Industrial Revolution to an economy enabled and supported by information technology. The term "Enterprise Architecture" (EA) was coined in the 1980s in relation to the impact of this shift on business roles and processes that create and use business data.
EA work should relate to the mission, vision, drivers and goals of a business, but it doesn't create them or architect everything that flows from them. EA has always been about business activities that can be wholly or partly digitized. Some digitization is tactical. Where digitization is strategic, then EA should be engaged in the definition of that strategy, but EA may contribute little or nothing to other elements of business strategy discussed below.
Business directors are responsible for business planning. They respond to business drivers by declaring strategic directions and top-level goals/objectives. Business planning may involve 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: pricing, sales and service channels.
· Relationships: partners, in-sourcing and out-sourcing of operations.
· Resources: people, wages, machines, locations/buildings and other physical asset types.
· Management structure: sacking or appointing CxOs and restructuring the organization.
Enterprise and solution architects may both stimulate and contribute to business planning, especially in information processing businesses. Probably less so in a business that manufactures material things or provides face-to-face services. E.g. in a university, our kind of architect is not hired to architect the prospectus, courses, research projects, lectures, buildings, slide projectors or HVAC systems. However, when and where those things create or require business data, they may be of interest to EA.
It has been said that “enterprise architecture regards the enterprise as a system, or system of systems”. The defining features of a business that make it a kind of "social system" are the memories and messages by which actors store and exchange information (directions, decisions and descriptions) in regular or repeatable ways.
The systems of interest are those in which business roles and processes create and use business data. These systems feature human/people and computer/technology actors performing activities to meet given aims/goals. Actors, activities and aims may be integrated by the exchange of information within and between systems. The systems may be changed under change control.
In short, where business problems, needs and opportunities relate to business activity systems that create and use business data, EAs may take a leading role. If it ain't to do with extending, improving or securing business activity systems that create and use business data, then somebody else - perhaps business directors, managers or IT architects - has the primary responsibility.
The PRISM report of 1986 divided architecture into four domains: Business, Data, Applications and Technologies (BDAT). Give some aim, problem, need or opportunity, architectural design methods usually work in sequence from B to T.
· B = business roles and processes performed by actors to meet business goals.
· D = information created and used in the course of B.
· A = applications bought, hired or built to capture, create and use D.
· T = infrastructure (hardware, OS, DBMS, middleware, networks etc) needed by A.
EA has always been about extending and improving B by extending and improving the capture, quality and use of D, by extending and improving the portfolio of A which depend on T. That is why EA is usually more central to businesses based on information processing, and less central to business that process materials or offer face-to-face services.
Generally, given some business goals, the first step is to identify or define the business services to be provided, and the roles and processes needed to complete them. After that, the required business data. application service contracts, use cases and user stories are business concerns before they are IT concerns.
The number of roles called “architect” varies widely between organizations. Some enterprises have never set up an EA practice; some have done so and struggled to make an impact. However, many do have a team called “Strategy and Architecture” or the like.
EA takes a cross-organizational and strategic view of business activity systems. It works to integrate business system planning with business planning. The term solution architecture is used at a narrower and more tactical level; often in relation to one particular system, or a process that requires system integration.
Solution architecture leads to more detailed design work and to software development projects. A solution architect may shape and steer a project (be it agile or not), keep it on the rails and in step with more strategic cross-organizational thinking. A software architect may elaborate a given solution architecture, complete the component structure and APIs of an application, and address the detailed design of messaging between applications or components. For discussion of “Microservices”, read this article.
Given the 4 architecture domains and 3 levels, every enterprise has to work out for itself how its roles cover the 12 cells of the table below. The weight given to each of the domains and levels differs between initiatives, and influences which architects are assigned to it.
|
Domain Level |
Business |
Data/Information |
Applications |
Infrastructure technology |
|
Enterprise |
Business
services, processes & roles, standardisation,
integration and
road maps |
Business
data stores and flows, standardisation,
integration and
road maps |
Business
application portfolio standardisation,
integration and
road maps |
Platform
technology portfolio standardisation,
integration and
road maps |
|
Solution |
Outline
design of a solution’s required
processes |
Outline
design of a solution’s data
architecture |
Outline
design of a solution’s application(s)
architecture |
Outline
design of a solution’s IT
production environment |
|
Detailed design |
Detailed
design of processes,
use cases |
Detailed
design of data
stores and flows |
Detailed
design of software
architecture |
Detailed
design of IT
production environment |
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.
This article goes on to say more about the enterprise and solution architect roles, and challenges facing EA today
Enterprise and solution architects don’t design buildings, cities or other concrete structures. Their concern is the design of business activity systems in which human and computer actors perform activities to deliver services. They work to extend and improve business roles and processes that create and use data that is or can be digitized. They play a role in selecting technologies that are used to support and enable those processes.
Solution architects work on specific initiatives. They respond to requests for architecture work and solution visions. Their work spans all four (BDAT) architecture domains. A solution architect shapes and steers a solution by:
· compiling a Solution Outline or Solution Architecture Definition
· coordinating the work of specialists working across the BDAT and security domains
· identifying and mitigating technical and non-functional risks
· defining a baseline to target migration path
· working alongside a project manager
· starting with the business context, working with business analysts as need be
· understanding a variety of alternative technologies in the DAT domains
· understanding alternative design patterns and making trade-offs between them
· balancing the demands of project managers and enterprise architects.
Enterprise architects have a wider remit. They work at the cross-organizational portfolio and strategic level to:
· optimize, standardize and integrate business roles, processes and systems
· constrain waste and issues caused by point solution proliferation and duplication
· maintain a summary description of the enterprise and its systems
· maintain standards, principles, reference models and patterns
· contribute to business strategy with advice on where changes and innovations can help
· develop roadmaps for changes and at a strategic, executive-level
· guide and govern architects working at lower levels.
Their scope may be a whole business, or a division or segment of a business, and includes interfaces to systems governed by others. They may collaborate in cross-business initiatives such as the Tele Management Forum. They may support business directors and planners in the design and planning of a major “digital transformation”.
To put it simply, enterprise architecture is portfolio-level thinking. It is strategic and cross-organizational planning of changes to business systems that are now or will be digitized to some degree. Whereas solution architecture is project-level thinking - about the design and planning of discrete systems/solutions. The roles overlap, and each may be divided between two or more people.
The Skills Framework for the Information Age (SFIA) is an international standard. It defines roles for people involved in designing or changing business systems that use information and communication technologies.
|
Role |
Responsibility
level |
||||||
|
Enterprise
architecture |
|
|
|
|
5 |
6 |
7 |
|
Solution
architecture |
|
|
|
|
5 |
6 |
|
|
Project
management |
|
|
|
4 |
5 |
6 |
7 |
|
Business
analysis |
|
|
3 |
4 |
5 |
6 |
|
|
Business
modelling |
|
2 |
3 |
4 |
5 |
6 |
|
|
Requirements
definition and management |
|
2 |
3 |
4 |
5 |
6 |
|
|
System
design |
|
2 |
3 |
4 |
5 |
6 |
|
|
Database
design |
|
2 |
3 |
4 |
5 |
6 |
|
|
Software
development |
|
2 |
3 |
4 |
5 |
|
|
|
Database
admin |
|
2 |
3 |
4 |
5 |
|
|
SFIA positions EA and SA as senior, leading roles. Both are concerned to shape and steer projects that change business roles, processes, data structures, applications and infrastructure technologies from a baseline to a target state.
For a large and diversified enterprise, TOGAF includes a segment level of architecture between EA and SA. Below is a summary interpretation, based on a thorough reading of the whole standard at versions 8 and 9.
Enterprise architects, according to the SFIA standard, “set strategies, policies, standards and practices”. In TOGAF also, they work at the cross-organizational portfolio and strategic level.
Segment architect is the term in TOGAF for an enterprise architect working in one division or domain of a wider organization to:
· act as enterprise architect for the portfolio of solutions/systems in their business area,
· maintain a description of their division or domain and its systems,
· develop roadmaps for change at a portfolio or program or level,
· govern architects working at lower levels.
Solution architects, according to the SFIA standard, “guide the design and development of integrated solutions to meet current and future business needs.” And “coordinate design activities, produce logical models of components and interfaces, and more detailed designs.” In TOGAF, solution architects may be engaged to
· shape a solution and join up the technical specialists who work on it.
· address the problems and requirements of a particular business operation,
· deliver a new or changed system using particular information technologies,
· guide projects managers as to the time, cost and risks of project-level work,
· maintain descriptions at the solution outline or high-level design level,
· develop roadmaps for change at a project or release level,
· govern project workers (designers, technical specialists, developers etc.).
Research into real architect roles shows a wide variety of role definitions. A selection of architect role definitions are posted in the left-hand column of this “Enterprise architecture roles and realities” page. You'll find articles on architect roles by level and by domain, and a slide show on the EA manager role.
To generalize, it is clear that soft skills are important, both EA and SA roles require communication and leadership skills. In addition, they are expected to have a holistic understanding of a business and the technologies it uses.
Generally, architects start from the business context and human activities. They design and plan changes to business systems - under change control. They aim to:
· support and enable business roles and processes that create and use business data.
· improve the efficiency and effectiveness of business processes
· extend and improve the gathering of business data, its quality and exploitation
· make cost effective use of modern technologies to capture, store, transmit and exploit business data.
Business systems evolved over millennia by formalizing the roles and rules, messages and memories, of social systems. Every business depends on sending and receiving messages, and remembering what has been done to date. Business roles and processes have always required technologies for information storage and communication.
Since the dawn of the Information Age in the 1960s, business systems have increasingly been “digitized”. Many IT departments took on the role formerly played by Operational Research departments. And people have recognized opportunities to “digitize” more and more business activities. We can:
· increase the speed and accuracy of billing and accounting.
· digitize employment records and tax collection.
· process cash using ATMs and point of sale devices.
· digitize money handling using card readers
· measure resource consumption using digital meters.
· replace snail mail by email
· do market research by capturing and analyzing information about customers.
· digitize our shop window on the internet.
· advertise and deliver services via social media.
· apply machine learning and other kinds of AI to our business data.
Digitizing data and automating processes is difficult, detailed and yet also abstract work. People have looked to formalize how the work is best organized. In the 1980s, the UK government’s method (SSADM) was based on these principles:
· Business options before technology options
· Logical design before physical design
· External view (interfaces, inputs and outputs) before internal view (system structures and behaviors).
SSADM progressed from business options through logical information system modelling to physical technology options and implementation. The principles remain sound, but some criticized SSADM for leaving physical and technology considerations too late. Before committing to project work, stakeholders wanted to see a top-to-bottom view of all four architecture domains.
Most architecture frameworks (e.g. IAF and TOGAF) and modelling languages (e.g. ArchiMate) still divide architecture into domains along the lines in the PRISM report.
· Business organization: Business roles and processes, shaped by the needs of the business to serve customers.
· Data/Information: Data structures in data stores and flows: shaped by the needs of business roles to monitor entities and events and communicate facts and directions.
· Applications: Use cases and the business applications that enable them, shaped by the needs of business roles to capture, report, move, store and process data.
· Infrastructure technology: Platform technology apps, nodes and networks, shaped by the needs of business applications to perform generic computing tasks.
Nowadays, in addition to the domains/layers above, attention is given to security architecture, which is applicable to each domain.
A “solution architecture definition” or “solution outline” captures a holistic view of the system(s) to be built or changed. The document, addressing all domains above, is produced for one or both of two audiences - for approval by stakeholders - for use by those working in detailed design and development.
Solution architects respond to particular problems, requirements and opportunities by shaping proposals for changes to business systems. They can and should play an active role in the following project(s), to steer and join up analysts, designers, builders and technical specialists. So, what is or should be the role of an enterprise architect?
The Information Age brought new opportunities, but also new difficulties. It turned out that designing, building, testing and rolling out a digital business systems is exacting work. And changing those systems can be just as difficult.
Business managers had specific requirements to support/enable, speed/scale up, optimize/extend particular business systems. They employed architects who defined solutions independently of each other – under the influence of competing technology vendors. Thus, the enterprise acquired a portfolio of systems that were not standardized, not integrated and did not share common data or services. Some systems stored different version of the same data, some did not interoperate, and many were tied to particular technologies.
Enterprise architecture was initially a reaction to issues caused by diverse silo solutions. (Note that the same issues may appear today as a result of over-enthusiastic division of applications into “microservices”!)
To begin with, note the 4Ds:
· Duplications of data and processes – leading to costs
· Disintegrities between data in different systems – leading to quality issues
· Delays in completing processes
· Difficulties with cross-organizational data analysis.
Then, add issues and diseconomies created by maintaining a mess of disparate applications and technologies:
· Technology dependencies - business roles depending on vendor-specific technologies.
· Complexity in the use of technologies to move data between applications
· Complexity in the effort needed to align or transform between different data formats
· The cost of resources and licenses for duplicate and overlapping business applications.
The pains are felt at the business level. Business coordination is weak because silo systems make it harder to integrate business roles and processes. For example, sales and billing systems, or social and health care systems, are inconsistent and uncoordinated. Business systems are inflexible, because digitizing and codifying can make it hard (or impossible) to change business roles and processes.
Above, EA is seeing and designing a business as a coordinated collection of human and computer actors performing activities to meet aims. EA is defined similarly in this article.“We define enterprise architecture as the holistic design of people, processes, and technology to execute digitally-inspired strategic goals.”
An enterprise architecture is a model or description an enterprise's business activity systems, at the most abstract level of business system design. Why define one? The same article says: “Every negative customer interaction via a company app, website, telephone call, or service provider exposes your architectural inadequacies. “Left unresolved, these issues will destroy formerly great organizations.”
Enterprise and solution architects may stimulate and contribute to business planning of the kind mentioned above. But their primary concern is business system planning.
|
Business Planning |
Business mission, vision, drivers, strategies,
goals and top-level business plans. Mergers, acquisitions, divestments,
internal organisation restructurings and rationalisations. |
|
|
Enterprise Architecture (Business Systems Planning) |
Business Architecture |
Business functions/capabilities, roles,
processes/value streams and their interrelationships. The services they
provide to each other and to entities in the business environment. |
|
Information System Architecture |
Applications and their interrelationships The services applications provide to each other
and to business activities. Data stores and data flows, the data structures
they contain and the qualities of that data. |
|
|
Technology Architecture |
Platform technologies and their
interrelationships The services technologies provide to each other
and to business applications. |
|
EA has always been challenging, both technically and politically. In the 1990s, the US OBM Memoranda 97-16 guidance on enterprise architecture declared that. “the balance between centralization and decentralization and the pace of change within the agency, should be clearly understood.”
What if nobody sees a need for current “silo systems” to interact? Suppose the only business-wide view required is financial summary information collected from disparate business units? A highly diversified business presents a challenge to the notion that the enterprise is a holistic system.
Still, a Strategy and Architecture team has a role to play in governance of solution architects working on discrete business systems. Suppose your enterprises wishes to standardize, integrate and optimize systems to the benefit to the enterprise as a whole, and mitigate change risks. Then it needs standards, principles, reference models, best practices and road maps for business system change. And it ought to govern solution architects with reference to those things.
Where there is little sponsorship or enthusiasm for following an EA framework, a more agile EA approach might be considered. There are several articles on agile architecture at http://avancier.website.
Go to http://avancier.website for enterprise and solution architect training courses.
Read Other EA challenges for populating your strategy and architecture team, governance of solution architects by enterprise architects, and “Guerilla EA”.
For real architect role definitions look in the left-hand column of this “Enterprise architecture roles and realities” page.
For the relationship of EA to Science, Biology, Psychology, Sociology and Philosophy, try "The Book" at https://bit.ly/2yXGImr
The term "EA" emerged in the 1980s, in connection with the authors below.
1970s: Duane Walker's Business System Planning (BSP), developed at IBM.
1982: Influenced by Walker, John Zachman proposed a 6 by 6 IS Architecture Framework. He said business information systems analysis should be raised to the “enterprise-level”. At least once in the 1980s, Clive Finklestein suggested Zachman use the term EA.
1980s: James Martin's Information Engineering. (I think James Martin did speak of EA).
1986: The PRISM report outlined four architecture domains (BDAT) used in today.
1989: The NIST EA model (reputedly the first publication with "EA" in the title) came out of the 5th Information Management Directions workshop. "Analysis of the business processes determine the information needed and processed by the agency"
1993: Stephen Spewak published his EA Planning method, again focusing on business processes that create and use business data.
2000s "EA as Strategy" by Ross, Weill and Robertson, again focusing on standardization and integration of business processes that create and use business data.
A comprehensive architecture methodology or framework provides guidance on the architecture processes, products and people. The process is the design and planning of changes to business systems. The product is the description of an enterprise's business systems, and how they relate to each other. That description, being multi-dimensional, is best recorded in a repository
Meta models for an architecture repository have been around for half a century (long before TOGAF and BizBOK). Perhaps the first was that of IBM’s Business System Planning, created by Duane Walker in the 1970s and inherited by John Zachman c1980. It set the pattern for other EA meta models in the 1980s and 90s. If I have it right, the Business System Planning meta model features the 7 entities and 8 relationships below.
· Processes <solve > Problems
· Processes <are performed by > Organizations
· Processes <create and use> Data entities
· Process <are enabled and supported by> Applications
· Data entities <represent> Business entities
· Data entities <are maintained in> Data stores
· Applications <access> Data stores
· Organization <use> Applications
Again, notice the focus on Process and Data rather than Technology. Today’s EA frameworks are still concerned with optimizing, extending and changing business processes that create and use data. First, enterprise architects should understand the systems of the business, not necessarily in depth. Then, they should understand what information technologies do or can do to support and enable the business.
Zachman’s vision of the single enterprise-wide business database is not achievable. However, it remains a vision that helps to explain that EA is about the portfolio of business systems. If there is no cross-organizational view of business processes and data, then there is no EA. If there is no architect using that view to steer the portfolio of business systems, then there is no enterprise architect.
Enterprise and solution architects work to support and contribute to business planning by business system planning. They look to optimize and extend business roles and processes, and exploit the use of business data. They attend to the digital technologies required for that; and govern more detailed design work.
Our architects do not shape and steer everything in business. They look for opportunities to digitize roles and processes, or capture new and useful data. But naturally, much of what people do in a business is ad hoc, irregular, intuitive or unrepeatable. It is impossible to digitize roles and processes that are changed by actors on the fly, or use unknowable heuristics. And that is OK; some things are best left to human judgement and informal processes.
Our architects may optimize how a road gang leader gets job instructions and delivers job a completion report.
They don’t advise road gang members on how to wield a spade when digging holes. (Though operational researchers or specialist consultants might do that.) They don’t design car production lines, or pharmaceutical research equipment or projects. They don’t design generic IT (platform/infrastructure technologies) or data centers.
Our architects are not business managers or business change consultants. They rarely design an organization’s management structure. They are not responsible for hiring, firing and motivating people. They are not human resources specialists, or sociological systems thinkers. Where employee roles are affected by business system change, they often work alongside a “business change” and/or HR function.
All free-to-read materials at http://avancier.website are paid for out of income from Avancier’s training courses and methods licences.
If you find the web site helpful, please spread the word and link to avancier.website in whichever social media you use.