Dr. Alex Pavlak, Thales Research, Inc, 315 Dunham Ct., Severna Park, MD 21146; 410.647.7334, thales@comcast.net 1

March 8, 2005

SIMPLIFY ENTERPRISE ARCHITECTURE

We can simplify the creation of new architecture by clearly separatingsynthesis from design and executing the former with expert teams.

OMB Circular A-130, DoDAF, and most Enterprise Architecture (EA) texts describe EA as a changemanagement process - current and target architectures with a transition plan. These sources are eithersilent or provide only weak guidance about how, exactly, one creates a new target architecture.

Marching through the change management methodology can create target architecture when thereis not too much difference between the existing architecture and the target. That is, for a small welldefined Enterprise and/or for small changes. This change management approach can obscurefundamental choice by introducing too much detail too soon when:

• There are many complex options for the future architecture.• The future architecture is unprecedented and is substantially different than the existing

architecture.• Enterprise function, not just data, is important to the fundamental organization of the

enterprise.

This paper looks at EA form the perspective of 2,000 years of Classical Architecture. The primarylesson is: separate synthesis from design and execute synthesis with expert teams. Expert teams havea long and robust history in Classical Architecture.

Classical Architecture

Classical Architecture begins with a vague expression of need. It begins with “We want to send aman to the Moon” or “I want my dream house.” There are no clear concepts or firm requirements,indeed requirements change and are part of the architectural tradeoffs. There may be constraints: “wewill send a man to the moon in ten years,” or “the house will cost no more than$500,000.”

Rechtin (Systems Architecting: Creating and Building Complex Systems, PrenticeHall, 1991) defines the purpose of Architecture as to synthesize concepts,satisfactory and feasible problem-solution pairs. From the perspective of classicalarchitectural, concepts provide the client with the basis for a value choice.

For example, consider rebuilding the World Trade Center. The owner hosted anarchitectural competition and provided Architects with general guidelines. A&Efirms responded with concepts expressed as models with approximate costs. Eachconcept was defined to a level of detail necessary to enable the client to make achoice. There is no unnecessary detail. Any one of those concepts weresatisfactory and feasible, the selection was a value choice.

Dr. Alex Pavlak, Thales Research, Inc, 315 Dunham Ct., Severna Park, MD 21146; 410.647.7334, thales@comcast.net 2

Selecting a concept is to select an unambiguous preliminary specification, a complete though highlevel functional description of the system. This specification kicks off the system engineering designphase. The designer allocates the functional requirements to lower levels of detail, models thefunctions, details the interfaces and optimizes the system within the constraints of the preliminaryspecification. System design begins with an architectural concept and ends up producing an optimalsystem specifications sufficiently detailed to specify procurement.

Classical Architecture process model

The Classical Architecture model is a waterfall, anon-iterative sequence of steps. The architecturephase develops a range of visions into satisfactoryand feasible concepts. A single concept is selectedto design and build. There are several salientpoints:

“Optimum architecture” is an oxymoron. Withinthe Classical Model, there is no such thing as anoptimum architecture because there are norequirements or other basis for optimization. At thearchitectural stage, requirements are part of thetradeoffs.

Within the classical model, architecture selectionis a one-time event. There is no iteration; architecture is not a living thing. Nobody is going tochange the architecture of the George Washington Bridge after it is built. Indeed the whole point ofarchitecture is to exploit a stable foundation on which to make long term investments.

While architecture is stable, the design can evolve. The George Washington Bridge added a secondlevel, security and traffic management systems, new access ramps. The F-16 fighter aircraft had astable airframe (architecture) that underwent many upgrades: engines, weapons, sensors, avionics.

In classical architecture, the separation between architecture and engineering design is anunambiguous specification. The architectural phase is all about function, figuring out what it is thatthe client wants to build. The engineering design phase is all about form. We have a clearunderstanding of the concept and the challenge is to optimize the design.

Enterprise Architecture Today

Enterprise architecture has its roots in information systems. John Zackman, an IBM systems analyst,conducted the seminal work in the mid 1980's. His “Extending and Formalizing the Framework forInformation Systems Architecture” (IBM Systems Journal, 31:3, 1992) has evolved into the ZachmanFramework - a data documentation framework. The Zachman framework is an excellent method fororganizing information.

Dr. Alex Pavlak, Thales Research, Inc, 315 Dunham Ct., Severna Park, MD 21146; 410.647.7334, thales@comcast.net 3

At its core, EA today employs a straightforward change management methodology. Wehave a present system, a future system and a transition plan that migrates from the presentsystem to the future system. One challenge is to figure out the architecture of a futuresystem when the present is mired in a morass of incompatible legacy systems. Classicalarchitecture suggests a stable distant vision (architecture) with a complex transition plan.Sorting this out involves perception and judgment, a task for expert teams.

Data Documentation Frameworks vs. Functional Frameworks

In recent years a number of Frameworks have emerged for specific applications. DoDAFhas evolved out of C4ISR to satisfy the needs of the Department of Defense.

Classical Architecture is all about function. During the synthesis phase classical architects work withFunctional Frameworks: functional analysis, aggregation, partitioning, and interfaces. It is importantto distinguish between “functional frameworks” which are useful during the architectural phase, and“data documentation frameworks,” the product of the system design phase. Data DocumentationFrameworks detail and document known architectures and may be of little help synthesizing newarchitecture.

The reason why the Zackman Framework is not often used for EAis that it does not align well with Enterprise function. ScottBernard (An Introduction to Enterprise Architecture,Authorhouse, 2004) developed a framework he calls EA . EA3 3

provides an excellent high level functional description of almostany enterprise ranging from the local body shop to theDepartment of Agriculture. EA can serve both as a functional3

and data documentation framework.

Design Drivers

The architecture of complex systems is usually driven by a smallnumber of “design drivers.” These design drivers are constraints andfunctions that primarily determine the fundamental structure. Othersystem functions are derivative or have secondary importance.

For example, with Apollo moon mission, the design drivers were mass,and the number of astronauts that would set foot on the moon. Theseconstraints determined spacecraft staging, an architecture where thelunar lander would consist of two parts, a decent stage that would beleft on the moon, an ascent stage that would rendezvous with theorbiting command module. It is absolutely critical that these designdrivers be identified early and that appropriate decisions be madeclearly, without obscuring fundamental relationships with unnecessarydetail. This task requires expert judgment.

Dr. Alex Pavlak, Thales Research, Inc, 315 Dunham Ct., Severna Park, MD 21146; 410.647.7334, thales@comcast.net 4

Architectural synthesis vs. system design

One reason to separate synthesis form design is that these are two very different tasks: differentgoals, different tools, different skills, and different people.

Synthesis begins with a fuzzy need; requirements are part of the tradeoffs. The purpose of synthesisis to develop satisfactory and feasible concepts. Synthesis employs creative inductive reasoning. Theanalysis consists of back-of-the-envelope calculations, heuristics, and empirical guidelines. Thefocus is on function, system drivers, interfaces, and functional misfits; don’t sweat the small stuff.Functional Frameworks are a useful tool. The products are coherent concepts with an unambiguousfunctional description. Expert creative problem-solving teams are well suited for architecturalsynthesis.

Design begins with a concept, unambiguous requirements. Its goal is to detail and optimize a systemthat can be built. Design employs reductionist deductive reasoning. The analysis consists of riskadverse logic, critical thinking, functional allocation, interfaces, the ‘ilities. The focus is on detail -make sure everything is covered. Data Documentation Frameworks are a useful tool. The productis an optimized system specification. Coordinated project teams are well suited for system design.

Separating synthesis from design allows the synthesis phase to focus on fundamental relationshipswithout being obscured by unnecessary detail. It clarifies fundamental choices. It allows the highmanpower detailed design effort to focus on a single concept and not waste time detailing systemsthat will not be built.

Architectural synthesis is not always necessary

System design is not always preceded by an architectural synthesis. The client may point to aprecedent and say I want one of those but make it smaller. In this case the preliminary systemconcept is the precedent. This is the case if we have a robust existing architecture and the futurearchitecture is a modest upgrade. Change management methodology would work quite well.

Architecture is an appropriate way to manage functional complexity. If a robust precedent exists andfunctional complexity is not there, a synthesis phase is not necessary.

The role of architectural teams

Architectural teams have a long and robust history. Most large and/orunprecedented systems were the product of a small team.

Architectural teams are creative problem-solving teams that develop closurein support of a unified vision. On the divergent side of creative problem-solving, teams can out perform individuals because they build on eachother’s ideas to create a product is greater than the sum of the parts. On theconvergent side, their evaluation and judgement can be more repeatable

Dr. Alex Pavlak, Thales Research, Inc, 315 Dunham Ct., Severna Park, MD 21146; 410.647.7334, thales@comcast.net 5

than individual experts.

Architectural teams are more complex than basic coordination teams that are employed for systemdesign and project management. Basic teams are all about cooperation. They do not need to solvenovel problems or develop closure behind a simple coherent vision.

Modern Tiger Teams

Traditional Tiger Teams consist of a small group of experts convened to solve a crisis. They can bespectacularly effective, but their performance can be unreliable. In “Modern Tiger Teams: Problem-Solving for the 21 Century” (http://mywebpages.comcast.net/thales/MTT.pdf) this author showsst

that reliable non-crisis performance can be obtained by integrating total problem-solving withadvanced teamwork. This includes:

• Deliberate participant selection. Individuals are primarily selected for discipline diversity, torepresent all of the important facets of the problem. For EA this includes both business processand information systems, two cultures that do not normally communicate well. Participantselection extends both horizontally, across organizational boundaries, and vertical, acrosshierarchical boundaries. Including key stakeholders assures their buy-in.

• Team Construction. There is an optimum size for face-face problem-solving groups. Tiger Teamconstruction becomes important when more than 12 people are contributing and when mixingremote and face meetings. Virtual meetings offer unique challenges.

• Split Leadership. Traditionally, Tiger Teams are led by a technical group leader which haslimitations. A more powerful form is to split the leadership role into content and process. Theprocess leader, respected by the culture, runs the meetings. The content leader assesses thevalidity and integrity of the content.

• Architectural heuristics. While team members implicitly know how to do their job, executingsynthesis as a team requires an explicit understanding of the task. The team needs access tocurrent best practices.

• Advanced teamwork. Everyone is familiar with basic teamwork that has the goal of cooperation.Advanced teamwork, characterized by Patrick Lencioni in The Five Dysfunctions of a Team(Jossey Bass, 2002) focuses on constructive conflict to resolve diverse perspectives.

The architecture synthesis task

The creation or synthesis of new architecture is an art form that has never been successfully reducedto a prescriptive formula. Instead there are many styles, the most appropriate of which depends oncontext. A variety of methods have been used, some of which are described in the DoDAF Deskbook(http://www.defenselink.mil/nii/doc/DoDAF_v1_Deskbook.pdf). The author’s large system successemployed expert teams and a functional balancing spiral.

The balancing spiral begins with an expert team aggregating the main functional components ofsystems that would satisfy the client’s need. This functional description is high level; all solution

Dr. Alex Pavlak, Thales Research, Inc, 315 Dunham Ct., Severna Park, MD 21146; 410.647.7334, thales@comcast.net 6

candidate systems would have this same functionaldescription. Bernard’s EA framework provides3

a functional description appropriate for many enterprises.

The team then brainstorms a comprehensive set of visions,selects a vision and begins to develop it using models toallocate the various functions, working the interfaces to fit thefunctions together. Experts identify and focus on the designdrivers, those functions that are most important to the systemconcept. Most functions are derivative or not that important atthis high level of analysis. The balancing process is empiricalan iterative art form, very much like tuning a piano. Everyeffort is made to keep the analysis simple and fundamental.

The Tiger Team develops the concept to the point where theyhave a preliminary system specification. They have approximate estimates of performance, risk andcost. The Tiger Team picks another vision and repeats the cycle. The final product is a set ofconcepts that are satisfactory and feasible solutions. The team is confident that they can be made towork. The concepts are not yet optimized. They are developed to the point where they can becompared with each other and the client can choose. This selection is a value choice.

Architectural process management

Following the classical architectural model, separating synthesis from design and executing synthesiswith expert teams results in a five stage EA waterfall management plan. The planning stage is basicproject management planning. The architecture synthesis phase was described above. Synthesis canbe viewed as a first pass, sparsely populating a functional framework. This stage also includesnailing the key elements and hard points of a transition plan. This architectural synthesis phase doesnot necessarily involve a lot of time.

Once architectures have beendeveloped the enterprise client canchoose one to detail. This selectioninitiates the design effort that is nowfocused on one architecture. Designinvolves fully populating anddetailing the framework andmanagement plan. This task mayinvolve substantial manpower andcan be managed as a traditionalproject. The product of the designeffort is an optimized systemspecification.

Dr. Alex Pavlak, Thales Research, Inc, 315 Dunham Ct., Severna Park, MD 21146; 410.647.7334, thales@comcast.net 7

Summary

EA is an emerging discipline. The central change management methodology - existing and futurearchitectures with a transition plan - is becoming well established. The creation of new architectureis less well established. Synthesis is particularly important when there are a large number ofcandidate future systems; the future system is unprecedented, substantially different than the existingsystem; the transition plan is mired in a morass of legacy architectures.

The main point of this paper is that we can simplify the way EA is practiced today by separatingsynthesis from design, and using expert teams to execute the synthesis. This separation clarifiesfundamental decisions and choices and allows the system design effort to be focused.

Modern Tiger Teams offer the unique potential to synthesize a robust big picture, the helicopterview. They can synthesize new architectures, reach beyond individual experience by building oneach other’s ideas. Through the reconciliation of diverse perspectives, they offer superior expertjudgement.

Biography

Dr. Alex Pavlak (PhD ME, PE) is an engineer who offers training workshops,coaching, consulting, and talks on the topics of Enterprise Architecture,Modern Tiger Teams, problem-solving, and system synthesis. For the past 12years, he has been investigating the limits of high performanceproblem-solving teams. Prior to 1992, Dr. Pavlak spent 25 years managing awide variety of R&D projects. In 1985 Dr. Pavlak led a team of scientists andengineers that synthesized the architecture of an unprecedented sonar system.