Enterprise Architecture Concepts

https://www.linkedin.com/pulse/20140622135614-86002769-enterprise-architecture-concepts

Enterprise architecture is widely misunderstood, and there is a deficit of trained and educated architects that can conceive of the full scope. There are several basic concepts you should be aware of in understanding enterprise architecture. Different schools of thought treat these differently, some including this and excluding that as adjacent, but they are each part of that picture. These concepts include:

• Strategic Planning
• Implementation
• Architecture
• Vision
• Alignment
• Transformation
• Strategic Advantage
• Technology
• Line of Business
• Frameworks
• Artifacts
• Business Processes
• Levels
• Areas
• Governance
• IT Investment
• Return on Investment
• Performance
• Portfolio
• Systems
• Lifecycle
• Integration

If your enterprise architects do not see the full picture and do not understand these basic concepts, you are not getting the full value of enterprise architecture. If you are an enterprise architect and do not see the full picture or do not comprehend how these basic concepts relate to your practice, you are not delivering the full value to the customer. As training, education and certification improve the full picture should, over time, become better understood.

Strategic Planning

Enterprise architecture is closely associated with strategic planning or IT strategic planning. Some view enterprise architecture as planning. A common main output of the enterprise architecture activity is a transition plan (aka roadmap or transformation plan).

Examples:
Steven H. Spewak’s book “Enterprise Architecture Planning, Developing a Blueprint for Data, Applications and Technology” ISBN 0-471-59985
Another book: Jeanne W. Ross et. al. “Enterprise Architecture as Strategy: Creating a Foundation for Business Execution” ISBN 1-59139-839-8
John A. Zachman: “During the 1980′s, I became convinced that architecture, whatever that was, was the thing that bridged strategy and implementation”.
The top policy for enterprise architecture of the U.S. Federal Government, OMB Circular A-130, transmittal 4, identified strategic planning as a direct input to enterprise architecture.

Implementation

Implementation of something is why you do an architecture. If you are implementing nothing there is little need to do an architecture. Without implementation the ROI (retun on Investment) for architecture is quite restricted, consisting of cost savings for what you did not implement.

Examples:
John A. Zachman: “During the 1980′s, I became convinced that architecture, whatever that was, was the thing that bridged strategy and implementation”.

Architecture

Atchitecture is about designing something to be constructed. It is a primarily visual practice communicated through drawings and specifications.

Definitions of ARCHITECTURE (ar·chi·tec·ture \ˈär-kə-ˌtek-chər\)
Merriam Webster: 2a : formation or construction resulting from or as if from a conscious act architecture of the garden> b : a unifying or coherent form or structure architecture>… 5 : the manner in which the components of a computer or computer system are organized and integrated
Dictionary.Com: 1: the profession of designing buildings, open areas,communities, and other artificial constructions and environments, usually with some regard to aesthetic effect.Architecture often includes design or selection of furnishings and decorations, supervision of construction work, and the examination, restoration, or remodeling of existing buildings.

Vision

Architecture is commonly considered to be a visual process. In architecture it is common to produce a “vision” or picture of the future state. Enterprise architecture also commonly produces a vision of the future (aka target or to-be) state. It is this vision which is commonly used to convince stakeholders to buy in to the direction and process of the architecture.

Examples:

• In the TOGAF framework there is a phase named “vision”.
• In the FEAF one output is a vision.
• In the DODAF the OV-1 CONOPS diagram provides a visual depiction of the future state, essentialy a vision.

Alignment

Alignment in enterprise architecture is when all the efforts “line up” to support the organizational strategy, or when lower level detail supports higher level architecture. When all the artifacts agree, you have “alignment”. Alignment is often checked by governance.

Examples:

One FEAF artifact, the “line of sight diagram” is a depiction of the project linked through improved performance measures to business outcomes and the organizational strategic goals.

Transformation

Transformation (aka business transformation or transformation of government) is the concept of changing the organization and its processes or structures to improve performance. Enterprise architecture is about transformation, expressing a current state a target state and a transition plan.

Strategic Advantage (Differentiators, Capabilities)

When a strategic goal or goals (aka “mission needs”) are supported by an executable implementation the result is a “strategic advantage”. A “strategic advantage” may also be called a differentiator (commercial use) or a “capability” (mainly government use). Enterprise architecture is commonly and routinely associated with the production of these “capabillities” or “differentiators” that constitute a “strategic advantage”. Many are unaware of this linkage because of disparate terminology, but one common definition of enterprise architecture is “the link between strategy and execution” which is again roughly synonamous. Michael Porter called this Competiitive Advantage.

Examples:

• TOGAF 9 includes a section of capabilities based planning
• DODAF is tightly associated with JCIDS (Joint Capabillities Integration and Development System).
• DODAF 2.0 includes a capabilities metamodel.
• Zachman International provides seminars for using EA to produce business advantage.

Technology

Definition of Technology (tech·nol·o·gy [tek-nol-uh-jee] noun):

… 4. the sum of the ways in which social groups providethemselves with the material objects of their civilization. (dictionary.com)

As the term is used here, technology is th basis of all strategic advantage, differentiators or capabilities. Initially EA was associated with only information technology, but wider applicability has since occurred.

Example:
In 1983 a classified program was initiated in the US intelligence community to reverse the US declining economic and military competitiveness. The program, Project Socrates, used all source intelligence to review competitiveness worldwide for all forms of competition to determine the source of the US decline. What Project Socrates determined was that technology exploitation is the foundation of all competitive advantage and that the source of the US declining competitiveness was the fact that decision-making through the US both in the private and public sectors had switched from decision making that was based on technology exploitation (i.e., technology-based planning) to decision making that was based on money exploitation (i.e., economic-based planning) at the end of World War II.

Technology is properly defined as any application of science to accomplish a function. The science can be leading edge or well established and the function can have high visibility or be significantly more mundane but it is all technology, and its exploitation is the foundation of all competitive advantage.Technology-based planning is what was used to build the US industrial giants before WWII (e.g., Dow, DuPont, GM) and it what was used to transform the US into a superpower. It was not economic-based planning.

Project Socrates determined that to rebuild US competitiveness, decision making throughout the US had to readopt technology-based planning. Project Socrates also determined that countries like China and India had continued executing technology-based (while the US took its detour into economic-based) planning, and as a result had considerable advanced the process and were using it to build themselves into superpowers. To rebuild US competitiveness the US decision-makers needed adopt a form of technology-based planning that was far more advanced than that used by China and India.

Line of Business aka Value Chain or Value Stream

A “line of business” is a particular product line. The term is also applied in EA to any functional area, including human capital, financial management, or logistics. A “line of business” is often the basis of an architecture inside the enterprise, and corresponds to the terminology “segment” used in Burk’s levels. Another term of similar use if “domain” as in “domain architecture”. A “line of business” may be a mission area or profit center, or it may be a support function or cost center. In EA the idea is to give priority to those areas that are important to the mission or produce profit.

In enterprise architecture the “line of business” or segment or domain is the level at which most business process reengineering, value chain analysis, supply chain analysis, operational analysis etc. occurs. An example of this is the Federal Segment Architecture Methodology. Another example is the Business Transformation Architecture (BTA) effort at DoD.

Frameworks

In enterprise architecture the “framework” holds a special role. In my opinion this is because enterprise architecture practice began with competing vendors in system integration, not in academia. Each participating company produced some competing conceptual model, and later this practice was adopted by government to conceptualize various parts of the practice. There are different types of frameworks, applicable to different levels and layers and mechanisms in the scope of enterprise architecture:

• Frameworks for solution architecture (DODAF, TOGAF)
• Frameworks for enterprise level architecture (ZIF, FEAF)
• Frameworks for segment (Line of Business) architecture (FSAM, DODAF tailored)
• Frameworks for enterprise architecture maturity (EAMMF)
• Frameworks for sequence, such as an SDLC (INCOSE SDLC, IEEE SDLC, DoD SDLC, DHS SELC)
• Frameworks for data or information architecture (Martin’s Information Engineering, Oracle Case Method tm)
• Frameworks for business architecture (Hammer’s BPR…)
• Frameworks for software architecture (Booch, SEI, UML)
• Frameworks for standards and infrastructure (COBIT)
• Frameworks for shared services (ITIL)

(Some believe in the ultimate “uber-framework”, a mythical super-method like the “theory of everything” in physics. Personaly, I do not think frameworks should be expanded from their focus, where they are excellent, into areas of mediocrity. For the moment we must use multiple frameworks, or parts of several. I suggest picking a minimum set and using them with improving maturity. Standard, public frameworks are superior to proprietary frameworks for which one must pay: Avoid being held hostage by vendors of frameworks with recurring fees or mandatory services.)

Artifacts

Artifacts come in various types:
Architecture & Engineering Drawings
Spreadsheets
Documents
Artifacts are the concrete output (deliverables) of an enterprise architecture effort. Sometimes these may be embodied in data inside a tool so you can create new artifacts on the fly. Artifacts (and the facts or plans they represent) are reviewed and approved via governance.

Business Processes

Enterprise architecture is the fusion of business and technology. This is accomplished in large part through business processes analysis and reengineering or continuous process improvement, the very same techniques used in human resources, operations management, logistics and supply chain management, Six Sigma, and TQM.

The US Government defines enterprise architecture in OMB Circular A-130: “What is the Enterprise Architecture? (a) An EA is the explicit description and documentation of the current and desired relationships among business and management processes and information technology.”
DODAF and derivatives include business process diagrams, and in DODAF these are labled “OV-5″ or operational view number five.

TOGAF identifies “Phase B” as business architecture, including business process analysis.

Levels

Levels in Enterprise Architecture

In 2006 Dick Burk, Chief Architect at OMB at the time, identified that enterprise architecture has different levels. This important conflict deconflicted endless arguments between architects at the tactical (solution) level and the strategic (enterprise) level. With the concept of levels in enterprise architecture practice it is now possible to see that there are three different kinds of activity with different scope possibly performed by three different teams (or more). Without this concept your EA efforts may become tactical and without strategic impact, or strategic but without concrete results.

Layers (aka Columns, Areas)

The concept of layers should not be confused with Burk’s concept of levels of enterprise architecture. In the NIST model five layers were identified (business, information, application, data, infrastructure), and these were modified for the FEAF framework as four levels (business, data, application, technology). Both are related to Zachman’s columns (all three images are from the FEAF where this is discussed). One could make a case that thiese layers relate to DODAF views as well. The concept of “layers” implies a flow from one to another, a precedence or order, as descrivet in NIST. Each of these layers consitiutes a different area or specialization in architecture and often a different member of the enterprise architecture team.

Governance

In enterprise architecture governance is used in the sense of corporate IT compliance, in the sense of Sarbanes-Oxley or Basil II. IT systems must comply with various laws, policies, plans, standards and higher level architecture. Enterprise architecture artifacts and system engineering plans are reviewed by governance processes. Those processes vary by organization.

Conversely actual systems are checked for compliance via testing.

IT (Information Technology) Investment

For several years now information technology has been managed as an investment. It is seen not as a cost of doing business, but as a means to improve operations. Information technology and IT systems have become massively expensive in large corporations and especially the U.S. Federal Government, and just buying some software because it seems useful is no longer justifiable. Each IT purchase is now managed as a means to effect organizational change, a way to make the organization perform. The cost is compared not to the system features and functions, but to the improvement in organizational operations and the decreased operations cost or increased revenue that will result.

This approach can be applied to any technology purchase, not just IT.

Return on Investment

The purchase of more information technology is treated as an investment. To justify the investment there must be a return on that investment, payback.
The return on any investment, including an IT investment, you list the tangible and intangible costs versus the tangible and intangible benefits. A document containing this information and making any ROI calculations is often called a Cost Benefit Analysis.

The benefits to the procuring organization are not system features but improved organizational operations. In the U.S. Federal Government more benefits are intangible, because it is politically infeasible to measure the dollar value of human suffering, starvation, death, or other things that may be affected by government operations.

Performance

Enterprise architecture improves organizational performance using technology, by leveraging technology investment. Organizational performance is made tangible by the use of performance measures. Performance measures may relate to money (cost, price), quality or timliness (throughput, volume). Any product or service or entire company can be measured in these categories.

Any business process can be measured and improved. These improvements also fall in the three basic categories of money (cost, price), quality or timeliness (throughput, volume). When you automate or streamline some business process these measures change. Such a change in performance constitutes the return on investment of the automation.

A measurable change in measured performance indicators is sometimes called a “business outcome”. When a new capability is operationally implemented you get a business outcome.

Portfolio

How do you decide which technology improvements to make in your organization, and which to cancel? If technology and IT procurement is treated as an investment, then you treat the question as a portfolio of investment. You perform portfolio management.

A portfolio of investment lists each investment, its cost, its level of return (return on investment), and its risk. You put the investment with the highest ROI at the top. Eliminate all the poor investments. Working from the top down, you draw a red line when you run out of budget for these investments. The investments above the line are what you fund, and those below are what you cancel.

As your investment proceeds you monitor that it performs as predicted. If the return drops or the risk spikes you review the investment for cancellation.

Systems (Theory & Engineering)

For some time the western world believed that if you could list every part of a thing, you understood that thing. Ludwig Von Bertanalfy changed that with general system theory. In GST things have interactions and you need to understand that. They have interfaces. Interactions may follow patterns, like strange attractors or cycles ammenable to Fourier analysis, or they may have cybernetic feedback.

Some such systems with many interactions may be complex. If you build a complex system you may need means to control and specify so many parts that no one person can grasp the whole thing. You may need system engineering. It has means to manage complexity.

Systems may be defined, like boxes. You may treat the internals as unknown and just specify the interfaces, black boxes. You may see inside and treat them as white boxes.

The enterprise is a system. Each IT investment is a system. Integrated sets of IT are systems. EA is meaningless without the concepts related to systems.

Lifecycle

Systems have a lifecycle. Typicaly there is a systemm development lyfecycle (provided by systems engineering) with stage-gates to mark major phases and transitions. The system is concieved, planned, developed, tested, operated and later disposed of. One system replaces another. All this takes time, and planning. Without that one system will break down as unsupporable and you may be in a huge rush to replace it with anything, perhaps not the best replacement, and you may be willing to spend extra to do it. The results of planning are reflected in the enterprise transition plan.

Investments also have a lifecycle, with reviews. These mark the ROI and the breakeven points, and should also be reflected in the transition plan.

Integration

Enterprise Architecture is a term initially coined within the context of addressing problems of system integration. To share information and support business processes from end to end it is typical to integrate systems together. Some years ago Manufacturing Resource Planning susye,ms were connected to accounting systems and ERP resulted, for example. There is still a strong need to connect systems together, via SOA, EAI, ESB or other means.

When you take items vended as a system, like ERP, and connect them to other systems you get a system of systems.