The Role and Development of an Enterprise Architect:

A Devils Advocate Perspective

May 2009

Robert S. Ellinger Ph.D.

Enterprise Architect

The Devils Advocate Thesis

The Problems
There is little respect given to the disciplines of the System Engineering, System Architecture, and Enterprise Architecture because
These roles and their responsibilities are poorly understood by various organizations management The personnel in these roles do not know how to perform their roles

There is little or no understanding on the part of Program Management of the role of customer requirements is IT system implementation
Cost and schedule are paramount (though everyone talks the talk) PM training and certification does not emphasize the importance of good requirements (customer, functional, and component) in creating and successful product while reducing both costs and schedule

There is little formal (or informal) training in requirements identification and management or risk management
e.g., the American Management Associations certification manual starts out the definition of a risk as A risk is an issue

There is no understanding that the Roles of Requirements Analyst, System Engineer, System Architect, and Enterprise Architect form a career path
2

The Problems
A Devils Advocate Position

The Problems
The Hardest Problems with Development of a New IT Product are:
Identifying the products requirements Deriving the System Architecture or functional design Identifying the risks (unknowns) associated with a design Ensuring that the product meets all of the customers requirements These are the problems that the System Engineer and System Architect address

The Hardest Problem with investing in IT Systems is:

Identifying which systems to invest in This is the problem Enterprise Architecture addresses

Responsibilities of the Systems Engineer

Responsible for the Systems Engineering Process that include:
Customer Requirements Management (RM):
The goal of RM is to clearly communicate the customers requirements to the developers/implementer such that the product meets the customers requirements it includes:
Identifying (not define) the customers requirements with the customer Evaluating the product the customers requirements to ensure meets the requirements

Identifying and managing risks

A risk is an unknown in the design All risks have technical, cost, and schedule impacts

Defining and managing issues

An issue is a problem in the design All issues have technical, cost, and schedule impacts Clearly identifying the root cause is difficult

Systems Engineering Hard Problems

Requirements Management1
Incorrect Fact (49% of All Requirements Defects) Omitted Requirements (29% of All Requirements Defects) Inconsistent Requirements (13% of All Requirements Defects)

Risk Identification and Management

A Risk is an unknown The hardest thing in a design is to know what you dont know. The second hardest thing in a design is to know what the probability and impact of the risk

Issue Identification and Management

An Issue is a problem Issues are simple to identify, but the root causes hard More difficult is to assess which are important to resolve and which are merely urgent.
[1]

Ralph Young , Effective Requirements Practices, (New York: Addison-Wesley: 2001), p. 80.

System Architect Hard Problems

Decomposing and Deriving the IT Functions a system must perform to have the system meet the customers requirements
The procedure of decomposition is
currently a black (or possibly white) art rather than a process or function It requires a good understanding of what business functions the system being implemented must enable and support. This requires a good understanding of all of the system engineering processes and procedures

The procedure of derivation of IT functions

currently a black (or possibly white) art rather than a process or function It requires a good understanding of the capabilities of IT functions the system being implemented. This requires a deep understanding of the Subject Matter (meaning the a system architect should be a SME in more than one area)

Structuring those IT Functions into a System Architecture

Creating a System Architecture is easy once the decomposition and derivation are completed properly Creating a good system architecture is harder, but the procedures are reasonably well understood

Allocating the Functions of the System Architecture to components in a cost effective manner
If the System Architecture is good, then the allocation process is relatively simple.

Enterprise Architecture Hard Problems

Clearly identifying Changes in the Enterprise Architecture to meet the organizations changing business requirements
Building a record of good IT investment decisions based on Enterprise Architecture

This must be done using the following:

Clearly Defining the current Enterprise Architecture
The IT Architecture of most organizations is sufficiently complex that by time it is implemented, parts of it are already obsolete Clearly determining the linkages among the layers of the enterprise architecture
This requires a good understanding of both the customers requirements and the system architecture

Maintaining the currency of the Enterprise Architecture

Same problem as above, but changing to meet a changing organizational environment The timeliness and cost of maintenance is not justified to management unless it can help with decision-making.
This is hard because it requires a change in thinking on the part of management Can only be done with good asset management processes and repository and good feeds from current IT implementation projects and programs

Identifying Disruptive Technology (Technologies that either challenge the organization or provide organizational opportunities)

The Solution
A Devils Advocate Position

Position Definitions
A Requirements Analyst (RA) supports the requirements identification and management process under the leadership/ mentoring of a system engineer senior grade. A System Engineer is responsible to the Program Manager for technical leadership on small and medium projects and is responsible to the System Architect on large project and programs. A System Architect develops the functional design and allocates to actual components. An Enterprise Architect supports the investment decision-making process to support the organizations mission and strategies.

10

Career Path of These Roles

Implementer Jr

Implementer

Implementer Sr

Requirements Specialist

System Engineer Jr

System Engineer

System Engineer Sr

System Architect

Chief Architect

Enterprise Architect

11

Requirements Analyst
A Requirements Analyst (RA) supports the requirements identification and management process under the leadership/ mentoring of a system engineer senior grade. While all developers and implementers work with requirements, identifying and documenting a good set of requirements is the most difficult task of a system engineer. Therefore, it requires the most experience, as well as some skill. This is the reason it is the first step toward becoming an enterprise architect.

12

Requirements Analyst
Areas of Expertise Development:

There are three areas of experiential learning to become a good requirements analyst: OpCons creation Under the tutelage of a Senior System Engineer or System Architect, the RA would work with customer to create an Operational Concept for the processes, which the IT system under development would support. Business Process Modeling and Engineering Under the tutelage of a Senior System Engineer or System Architect, the RA would work with the customer to structure and statically model the business processes to provide insight into the functions and interfaces the IT system under development would require. Requirements Identification and Management Under the tutelage of a Senior System Engineer or System Architect, the RA would work with the customer The candidate RA should have at least 5 years experience and worked two or more SME areas. The reason for this requisite is that this gives the candidate time to develop a feel for the requirements and risks in his or her areas of expertise and an understanding of these areas link with other SME areas. Additionally, it gives time for the candidate to develop the vocabulary necessary to write requirements understandable by many SME disciplines. The candidate should demonstrate the ability or communicate both orally and in written form. The reason is that the reason that a requirements process exists is to clearly communicate the customers real requirements to the developer/implementer. Clear communications is the key. The candidate should have at least 40 hours of training in the development of OpsCon and requirements identification and management. This is before starting as a RA.

Requisites

13

The System Engineer

A System Engineer is responsible to the Program Manager for technical leadership on small and medium projects and is responsible to the System Architect on large project and programs. The system engineer leads the requirements management, risk management, technical issues management, and configuration management teams and processes on most projects. The system engineer ensures that all of the customers requirements are validated and the all functional and component requirements are validated.

14

The System Engineer

Areas of Expertise Development
Requirements Identification and Management The System Engineer will be responsible to identify and manage requirements until the product provably meets the customers requirements. Risk Identification and Management With coaching and mentoring from a Senior System Engineer or System Architect, a System Engineer Jr. grade will work with the implementation team and customers to identify requirements, and will work risk team to assess and depose of risks. This disposition may include mitigation planning and executionthough not all risks are mitigated (risks can be accepted, avoided, or transferred as well.) System Engineers and System Engineer Sr. grades will not need coaching and mentoring. Issue Management With coaching and mentoring from a Senior System Engineer or System Architect, a System Engineer Jr. grade will work with the implementation team and customers to manage issues to closer, using an issue tracking and closure plan process. Configuration Management - With coaching and mentoring from a Senior System Engineer or System Architect, a System Engineer Jr. grade will work with the implementation team to manage the configuration of the system under development to ensure that the product developed is the one verified and validated and that the product evaluated is the one rolled into production for the customer. V & V Testing With coaching and mentoring from a Senior System Engineer or System Architect, a System Engineer Jr. grade will work with the implementation team and customers to evaluate the product being developed, in terms of both verifying that the components and functions perform to their requirements and to validate that the product meets the customers system requirements.

15

The System Engineer

Requisites
Two to five years as a system engineer with demonstrated competence in:
Two or more of the IT SME areas Including
Hardware and Operating System specialists that implement and maintain mainframe and server computing environments Software Development and Service Assembly creates, integrates and/or assembles application software Security that designs, implements and maintains IT security systems Database Designer that design, implement, and maintain database systems Network Analyst that design, implement and maintain the data networks interconnecting hardware computing systems

One to two years performing Requirements Analysis (as discussed above)

16

The System Architect

Medium and large projects and programs, especially those using SOA, will need system architecture. A System Architect develops the functional design and allocates to actual components. Normally, an experienced System Architect will mentor a new System Architect through at least to projects.

17

The System Architect

Areas of Expertise Development
System Architecture and Functional Design The key skill of the System Architect is creating the system architecture or functional design of the product the team is implementing or developing. The functional design derives the IT functions that will enable and support the processes within the organizational context. The System Architect will use the system architecture and allocate functions to components. Because, System Architecture, like all design disciplines, requires a high degree of intuitive understanding and creative ability, not all Systems Engineers will be able to make the transition from System Engineer to System Architect.
Decomposition is the process of dividing business processes and functions down to the point that corresponding IT functions can be derived to support them. This is a key reason for having a good understanding of the customers processes and requires experience to perform. Derivation is the process for defining and delimiting the IT functions necessary to enable and support the organizations processes. A significant amount of experience is needed for this task, as it is more of an art form than a transaction. Structuring is the process for organizing the functions and optimizing their number to effectively and efficiently enable and support the processes. A significant amount of experience is needed for this task, as it is more of an art form than a transaction. Allocation is the process of dividing the grouped functions as requirements into trade off studies to determine what and which COTS and custom components will best enable and support the System Architecture supporting the organizations processes. Again, an excellent technical grounding in the technologies helps.

Requisites
All skill of the System Engineer, practiced for at least two years.

18

The Enterprise Architect

An Enterprise Architect supports the investment decision-making process to support the organizations mission and strategies. This includes both identifying candidate programs and also identifying defects in governance, which cause the organization not to achieve is mission.
Enterprise Architecture is far different from any of the previous roles because it is the System Engineering Technical Advisors (SETA) to the management team making the IT investment decisions. In this role, the Enterprise Architect measures and models the current business processes to determine if the processes meet the organizations mission and strategies, and if and how well the current IT systems enable and support the processes. A new Enterprise Architect will need coaching and mentoring from a seasoned Enterprise Architect for at least two significant projects before being allowed to work independently.

19

The Enterprise Architect

Areas of Expertise Development

ConOps the Concept of Operations, differs from the Operational Concept in that the ConOps is about the integration and interaction of all of the processes and the governance supporting those processes, while an OpsCon is about how a particular system functions, or will function when upgraded. The ConOps guides all of the OpsCons for a particular organization (enterprise.) Further, the Enterprise Architect will need to consider all aspects of an upgrade, (e.g., are there personnel trained in the new or upgraded technologies.) Business Process Measurement and Modeling is the process of determining if and how well the organizations processes meet the organizations mission and strategies, how well the organizations processes support those strategies, and if and how well the IT systems support the processes. Enterprise Blueprints is the process for creating a notional design for an upgrade to replacement of an existing IT system, or the creation of a new system to more optimally support the organizations processes, strategies, and mission, in continuously changing operational and technical environments, as determined by the Business Process Measuring and Modeling process (above). The blueprints include business cases. Business Case Development is the process for determining the potential value of creating a new or updating an existing IT system. For those projects that management funds, the Enterprise Architect will later use the metrics of this business case to determine if the implementation project met the objectives as outlined in the business case.

20

10

The Enterprise Architect

Requisites
Two to five years as a successful System Architect Training in business case development, business process modeling, and creation of ConOps. Additionally, training in the FEA and DoDAF, and other enterprise architectural frameworks as necessary.

21

The Devils Advocate Position

Culturally, the true role of the Requirements Analyst, System Engineer, System Architect, and Enterprise Architect have to be recognized within the project, program, and organization or there is a significant probability of failure (especially when compared with organizations that do) Formal Training in Requirements Analysis and Systems Engineering processes, procedures, and methods is nice, but not essential; An apprenticeship approach is required for both Formal Training in Systems Architecture, coupled with a deep understanding of both Systems Engineering Processes and IT technology is essential to create good systems architecture and better guarantee a successful implementation project or program Formal Enterprise Architecture Training is nice, but not essential to the Development of an Enterprise Architect; an apprenticeship with a current Enterprise Architect is.

22

11

23

12