Enterprise Architecture and System Architecture

The discipline of Enterprise Architect is distinctly different from System Architect, though many confuse the two.  See the post, "The Definition of the Disciplines of Systems Engineering" for the definitions of the two disciplines.

Fundamentally, they are both sub-disciplines of Systems Engineering, and both deal with requirements, risks, issues, and evaluation, but are much more specialized in their roles, that is, what they use these Systems Engineering functions for.  The responsibilities of the Systems Engineer include working with the customer to identify the customer's programmatic (cost and schedule) and system (functions to be performed, and constraints on the design) requirements, identifying and managing risks (see my post "Risk Defined") and issues associated with the design, managing the configuration of the design, and ensuring that all of the customer's system requirements are met, through a verification and validation (V&V) process.

The responsibilities of the System Architect include transforming the customer's system requirements (see the post entitled "Types of Customer Requirements and the System Architecture Process" for the definition), as identified by the Systems Engineer, through decomposing them in a manner that enables the architect to derive the functions the deliverable must perform.  These are the system functional requirements for the deliverable.

The System Architect then structures and orders these system functional requirements (or system specifications) into a System Architect (or Functional Design).  The System Architect then has the responsibility to segment the System Architecture into closely coupled groups of the functions.  Once the System Architect has a system architecture segmented, he or she will allocate the grouped functions as component requirements for a trade off study, using these requirements as the criteria for the trade.  Additionally, the architect will add any required design constraint requirements to the allocation.

The Enterprise Architect has a much different role and responsibilities, yet the skill set is built on those of the systems engineer and system architect.  Fundamentally, the first responsibility of the Enterprise Architect is enable and support the decision-making process enables and supports effective and cost efficient investments in tools and processes that optimally advance the mission of the organization to reach its vision; I call this the Mission Alignment process.  The second is to support the Governance and Policy Management processes to ensure that the organization's policies and standards enable and support the organization's mission alignment for achieving its mission, rather than inhibiting it from the achievement.

In this regard, for the Enterprise Architect, the Mission Alignment process produces the organization's requirements for performing activities to achieve its goal (the organization's performance requirements that are the analog of the system performance requirements for a project).  At the same time, for the Enterprise Architect, the policies and standards are the analog of the design constraint type requirements.  Consequently, the Enterprise Architect will use many of the same process patterns as the Systems Engineer--just applied to decision-making as opposed to transforming some portion of the architecture.

The post is an extension of a presentation I made at the 2009 SEI SATURN conference.

SOA Orchestration and Choreography Comparison

In Service Oriented Architecture, the definition of the concepts of Orchestration and Choreography have confused many people.  Here is my understanding of these two concepts, how they relate to one another, and how they may be used.

Definition of Orchestration

A technique used to compose hierarchical and self-contained service-oriented business processes that are executed and coordinated by a single agent acting in a "conductor" role.  (From OASIS Reference Architecture for Service Oriented Architecture Version 1.0 ,Public Review Draft 1, 23 April 2008, p. 69). 

Using the comparison of code compiler and interpreters as an analog, an orchestration engine ("the conductor") executes compiled process code as a complete application.  The composite application is complete before it is rolled out into operation, that is, all of the service components locations are known and the process flow is fully coded.  This means that there is no need for dynamic linking of service components. 

Generally, this also means that all of the service components exist within a single ownership domain.  Consequently, some SOA architects would define the environment within which orchestration is used as an Enterprise SOA.  Using "Cloud" terminology, this would be a Private Cloud at the SaaS and PaaS layers.

Definition of Choreography

A technique used to characterize and to compose service-oriented business collaborations based on ordered message exchanges between peer entities in order to achieve a common business goal.  (From OASIS Reference Architecture for Service Oriented Architecture Version 1.0 ,Public Review Draft 1, 23 April 2008, p. 71). 

On the other hand, using the same analog, a Choreography engine is like a code interpreter.  An interpreter executes or processes a single statement or step and then gets the next to execute; so it is a stepwise processor.  This is exactly the way Choreography works.  The reason that Choreography works this way is that a choreography enables a composite application to dynamically link to its service components.  This means that at each step in the process, the choreography engine can search and discover service components (across the Internet) that  meet its parametrized requirements and its internal policy and standard restraints and constraints.

Therefore, choreography is used when the service components for a given composite application exist in multiple ownership domains.  SOA experts frequently refer to this environment as an Ecosystem SOA; while cloud terminology would call this environment a Public Cloud.
  

When they Might be Used

Given the description above, it is readily apparent that Orchestration and Choreography have quite different characteristics and uses.

Orchestration:

• The composite application exists within a single ownership domain, so security of the composite application is less complex
• The organization can count on a given level of performance and can increase the performance with additional investments in its own service components and systems
• The organization can count on a given level of reliability
• There is stability in the operation of the system from the users' perspective (it does the same thing the same way all the time).
• If there are defects, the sub-organization responsible for the composite application can correct it without (formal or informal) contract negotiations.
• If new technology should be inserted into one or more service components, the organization owning the composite application can implement it without reference other organization's.

Consequently, organization's should always implement composite applications supporting "business critical" processes and functions using orchestration.

Choreography:

• The composite application exists across two or more ownership domains, so that in teaming, sub-contracting, and similar situations the dynamic linkage of Choreography is very helpful.
• If there is a highly specialized service component that is required to perform a particular function, then choreography is preferred.
• In intelligence gathering situations
• In non-core "business" functions.  For example, if you are the business of manufacturing ice cream cakes, then having a full time HR function, or even accounting function may not be cost efficient and is not part of the core functions of the organization.  Instead, they are sustaining functions, which can be outsourced.   In smaller businesses, linking to outside HR and Accounting functions for various services may, likewise, be sensible.
• Finally, if service components are treated as "apps for applications" then many of the benefits are the same as for end-user using "apps" on their wireless device.

The problem with choreography is that it is not within the control of the organization wanting to use it.  Consequently:

• It can't control the policies and standards used within the service component(s) that are outside its ownership domain; it can only contract for its use.  This means that it has little power to audit the service component other than for the contractual obligations, such as Service Level Agreements (SLAs).
• The standards and policies to which the services are built may change, so that a customer organization may need to either change it interface, wavier one or more of its policies and standards, or discover a new service.

So there are pluses and minisus to each.  Also see my Posts "Assembling Services: A paradigm shift in creating and maintaining  applications", "Asset and Enterprise Architecture Repository", and "Using Enterprise Architecture to Reduce the Federal Debt".

Some of My Favorite Sayings/Stories for System Architecture

The Principle of Superiority (also called the learning curve):

The first example of the superior principle is always inferior to a mature example of an inferior principle.

Corollaries include:

• The first roll out of a superior process is always inferior to a mature inferior process.
• The first roll out of a superior product (like the automobile) is inferior to a mature product (like the horse and buggy).  That is, it does not go as far; it goes more slowly; it's much less reliable; it's difficult to find "feed"; and it's dangerous to have that "feed" (gasoline) around because it could explode--when was the last time you heard of a horse or oats exploding.... 

The (Key) Principle of Optimizing Systems:

Optimizing sub-systems (e.g., functions, activities) always sub-optimizes the system. I've often wondered why system architect cannot take a lesson from manufacturing engineers--they balance the processes and tooling of an assembly line rather than allow private agendas of the functions be translated by a combined  process of beauty contest and back room dickering to dictate where to invest to optimize the effectiveness of the line.

The To Be Architecture Principle:

Start with the end in mind (to quote Steven Covey).  Have a big picture, but without much detail.  Acquiring the "detail" will take so much time that it will be obsolete before its ready to use.  Instead, remember that "the end", in this case, is the vision or long-term goal. Then "plan a little/build a little."  Choose where to start based on the initial objectives or mission. Then, at least if you're working in information technology like I have most of my life, choose one of two strategies, either implement the "low hanging fruit" first (first, implement the things that have the least risk associated with them), or implement "the hard" things first (first, implement the things with the most risk associated with them).  Either way, ensure that you have good configuration management and good V&V processes in place that are well executed--otherwise "the plan a little/build a little" approach will not work.

The Airport scheduling Algorithm:

Never over-schedule the runway.  The problem is defining what "over-schedule" means.  I once read in a systems analysis text, which I own but have not been able to locate, that an airport has two choices in scheduling; either schedule for the best case, or allow for some of the worst case or "imperfection" an attribute of being human.  For example, suppose that under the best conditions an aircraft can land or takeoff once every 30 seconds.  Some airports will plan for one aircraft every 30 seconds--Laguardia and Reagan National (before 9/11) seem to be two.  What happened and continues to happen when the weather conditions are not perfect?  Laguardia is known for taking an hour or more for a plane, from the time of push back to when it reaches the runway for takeoff.  See my post "Lean or Agile Enterprises and Architecture".

The Law of System and Product Development
Cost, Schedule, Quality; choose two of the three.  This may be a correlary of Arrow's Impossibility Theorm.

Process Effectiveness Versus Finance Engineering

In the 1970s, while I was working on my dissertation, which used a "time-sharing mini-computer" (with much less capability and perform than today's medium-smart phones), that when all 16 users worked the system to the point that it was using more than 50% of its "potential" Central Processing Unit (CPU) cycles, the throughput leveled off.  That is, at 60% the throughput was essentially the same, or slightly less than at 50%.  By the time the system was using 65% of its CPU cycle, the throughput had tailed off measurably.  And, by the time the system 85%, the users (student's) were going out for coffee after pressing the return key; literally, 90% or more of the CPU cycles were being used up in the administrative and management processes of the system.  Finally, when 90% of the CPU cycles were being used, there was no measurable throughput.

The thought has occurred to me often, that from a finance engineering perspective, using a computer to 90% of its rated CPU cycles would be considered much leaner and more economic than using it to 50% of those cycles.  Yet, my "informal" study (I did the research, but didn't write a paper) demonstrated the system was most effective when it was run a 50 to 60 percent capacity.

Since, I have seen many other systems that produce more when not run flat-out all the time.  I've often wondered why the transactional managers and finance engineers were never taught that.  The only answer I can come up with is that measuring effectiveness is difficult.