EATS Contextual View

Mission

The mission of Architected Futures is to deliver highly valued information engineering products and services to our customers, and to contribute to our profession, our industry and the societies in which we operate as valued citizens. The Enterprise Architecture Tool Suite is an integrated product suite of software and information models supporting enterprise architecture specification and management. It forms the foundation of the Architected Futures product line. It is intended for delivery as an end-product to our customers. It also forms the basis for the development of related consulting services.

Business Vision

The business plan of Architected Futures is to develop a suite of automated tools and services to support and promote the use of architectural engineering principles in the management of change in an enterprise. We believe that there is a significant need for such facilities in the management of modern enterprises, and that this need will become increasingly critical to success over time. Major factors involved in this trend include:

• a continued shift toward an information intensive environment,
• an increasing trend toward specialization of activities and outsourcing for non-core activities and support services,
• increasing regulatory demands placed on enterprise operations and management practices, and
• increasing dependence on information technology to operate enterprises.

All of these factors drive up the complexity of managing a modern enterprise. It is our belief that a key part of the solution to this problem lies in having a firm understanding of the architecture of the enterprise, what works and what doesn’t, what supports the enterprise mission and strategy and what doesn’t, and using that knowledge to re-engineer the enterprise on a continual basis.  Modern enterprise managers need more effective monitoring, measurement and control systems concerning the course and systemic health of the enterprise. It is our belief that the Enterprise Architecture Tool Suite is such a system and will provide unique insight and technical assistance to management in controlling and directing the course of change in modern enterprises while offering opportunities for efficiencies in day-to-day operations.

Approach

There is a growing body of literature advocating the development of enterprise architecture, most of which is related to information technology planning. The focus of the literature is on the alignment of the information technology assets of the enterprise with the core business function of the enterprise. Much of the literature talks about the need for the development of a business architecture as the basis for the development of an IT architecture. We are not in conflict with the viewpoint that the business architecture should be the basis for the IT architecture. However, we differ from the majority of the literature in the following ways:

1. We are addressing the development and maintenance of an architecture description for the architecture of the enterprise itself, for the purpose of managing the enterprise as an architected entity. Our target is not limited to the information technology of the enterprise; rather our target is the whole of the enterprise. The scope of enterprise architecture includes human components, IT components and other physical and conceptual components. It includes products and services and the means of production. It includes business plans and customer needs and their means of satisfaction. The architecture is not focused on any one of these components, but rather the synergistic whole of the enterprise. As a by-product of documenting and understanding the architecture of the whole enterprise, an architectural description of the components will be developed … if they are determined to be vital components to the operation of the whole. Otherwise their impacts on the whole of the enterprise will be documented and their internal architectures may be left un-detailed. This includes IT systems and their architectures1.
2. We firmly believe that architecture, good architecture, whether it is about buildings and cities, or about other human structures, including enterprises is not just about structural integrity and functional utility. An often overlooked or under appreciated viewpoint in architecture, especially when the focus is on IT, is quality and beauty. Enterprise architecture when developed from an IT perspective tends to focus on utility and economics. Good enterprise architecture needs to address all three of the architectural principles of utility, durability and quality as co-equal objectives. No one of these aspects holds absolute priority over the others.
   • Good architecture should be useful and it should satisfy the function for which it was intended in a reliable and efficient manner.
   • Good architecture should be structurally sound and robust. The architecture should function indefinitely as long as the functional needs do not change in too drastic a fashion.  It should be maintainable and adaptable and it should incorporate full life-cycle planning.
   • Good architecture should delight the people who interact with it. It should be pleasurable to use and it should boost the human spirit. It should enhance the quality of being of its users and the ecosystem in which it participates.
   • Good architecture should provide balance and harmony to the esthetic and structural forms used in the delivery of function such that no one of these aspects becomes an overpowering force to the detriment of the others.
3. We believe that developing or enhancing architecture can be approached from a myriad of viewpoints, and that no one viewpoint has primacy. Because of this we try to be methodology agnostic and forgiving regarding hard rules and strictures. This is especially true and important when dealing with dynamic rather than static architectures. We believe in quality, and our tool suite is focused on the development and measurement of quality in architecture. However, the tool suite will also allow users to break rules, fail to document necessary details, and document contradictory things; if that is what exists or is the limit of their understanding. We do this because contradictory operations and gaps in functionality are characteristics of real architectures. Once the conflicts have been identified, or the incomplete descriptions have been recorded, the tool suite can then be of assistance in resolving the conflicts, filling the gaps and helping to develop improved versions of the operational architecture.
4. We believe that it is imperative that the management of the policy, procedural and technical aspects of the enterprise be brought together and controlled as a unit in order to achieve effective alignment on a continual basis. Mechanisms which support reconciliation and re-alignment of discordant components are helpful, but optimal efficiency can only be achieved with the support of a tool that provides continuous feedback on all aspects of the enterprise – those that are obvious and reasonably sure to be checked, as well as those that are hidden or obscured and lost in the myriad of detail.

Rationale

The rationale for our approach is fairly straight forward.

• All of the components of an enterprise exist for the purpose of fulfilling the mission of the enterprise. To ensure cohesion and collective purpose, the components need to be viewed and managed as constituent parts of the whole.
• As a whole, the enterprise has architecture, a manner in which the parts relate to one another in the course of conducting operational activities for the purpose of fulfilling the mission of the enterprise. The architecture exists whether it is documented or not, whether it is efficient and effective or not.
• To the extent the architecture is understood and communicated, the management and cooperative evolution of the enterprise is facilitated. To the extent the architecture is left implicit, the components tend to operate independently, there is an inability to analyze and evaluate beneficial and detrimental interactions between components, the basis for collective reasoning in making choices is lacking, the focus of the components in serving the enterprise mission drifts and the overall efficiency and effectiveness of the enterprise suffers.
• As the number and complexity of the components increase, and as the relationships between the components become diffused and dispersed, the difficulty of identifying and comprehending interrelationships and their impacts increases exponentially.
• Humans have tremendous powers of imagination, creativity and insight to address and solve problems, but poor capabilities in the simultaneous tracking and tracing of large volumes of details. Modern computers and information systems have tremendous powers of dealing with enormous volumes of detail in a rigorous and comprehensive manner, but poor capabilities in dealing with vague and esoteric logic or making value judgments.
• By providing a system for people to deal with small groups of related elements at a time, and by fitting those elements into larger systems of elements by means of a network of logical relationships the power of the computer can be harnessed to assist humans in focusing on the aspects of enterprise architecture that require their attention.
• Documenting multiple viewpoints of enterprise activities in a consistent manner over a consistently defined group of elements allows secondary and tertiary relationships to be exposed that either support the rationale and structure of a primary element, or call it into question.
• As more elements are described and documented, the evidence and cohesion of a composite organization, or the lack thereof, is exposed. As the cohesion is exposed and expanded on, confidence in the organizational alignment increases.
• When changes are desired or required, the ability to rapidly trace relationships and to perform impact analyses on alternatives provides a facility for enhanced communication of group goals and relating group processes to individual components, increased efficiency and problem avoidance; rather than expending of energies resolving problems after the fact. It also becomes easier to recognize and identify areas of component organization that are un-impacted or unaffected by alterations in group processes so those aspects can safely be left unencumbered or constrained during the transition process.

Product Conce​pt

Enterprise

An organization with a cohesive purpose to offer a product or service, and a strategy and means to accomplish the purpose. Includes profit making and non-profit businesses, governments and other types of organizations.

Architecture

The art and science of designing synergistic structures in a manner which achieves utility, durability, and delight to its users. The architecture of an object is the manner in which its components are assembled into a unified whole designed to satisfy a cohesive purpose. Architecture as a practice is the art and science of designing structures, systems of composite elements, into unified wholes to achieve that purpose. The quality of an architecture can be measured by its social relevance in terms of utility and satisfaction of function, its soundness of engineering and durability, and its esthetic characteristics and the ability to bring delight to its users.

Architectural Description

A collection of materials that describe the architecture of a specific object.  ANSI/IEEE-1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems is a formal engineering standard that establishes a set of content requirements on an architectural description for software systems that can be easily abstracted to apply to architectural descriptions for all systems.

Every composite structure has architecture. Some architecture is documented (have an architecture description), some are not. Some is good architecture, some is not. The architecture of a thing exists because the thing exists. Some architectural documentation is complete (sufficient), some (most) are not. The challenge for a dynamic enterprise is moving toward sufficient documentation to be able to measure and evaluate its architecture, and to be able to evolve the architecture to better serve the purpose of the enterprise.

There are different scales of architecture which require different scales of documentation. At very small scales, the documentation of architecture can be a nice to have, but far from a requirement in order to be able to maintain and manage the evolution of the thing. At very large scales, maintenance and management of even small changes can sometimes be difficult without an understanding of the systemic architectural impacts of the changes.

The architecture of buildings is sometimes used as a metaphor for explaining the architecture of systems and businesses. We believe that this metaphor is lacking when the comparison to building architecture is specified as a comparison to the architecture of a building as a static structure. The metaphor looses further value when the building in the metaphor is a house. The metaphor helps obtain quick comprehension, but tremendously under appreciates both the nature of enterprise architecture and the nature of civil architecture when issues of scale need to be considered.

Figure 1Architectural Scale in Different Domains

A better appreciation of the enterprise architecture and the role of an architect in participating in the development of that architecture can be obtained by providing a series of metaphors that vary in scale as shown in Figure 1. This diagram draws a comparison between the concept of architecture as applied to buildings and construction, the concept of architecture in terms of social organization, the architecture of enterprises, information technology architecture and the architecture of biological systems. In each domain there is a range of scales at which the practice of architecture can be applied.

Focusing principally on the Enterprise Architecture column from the viewpoint of business engineering we have a scale that increases in size and complexity from the architecture of jobs and work teams to departments and divisions to companies, to multi-product line companies and upward to conglomerates. The principals of architecture can be applied at any of these levels, but it becomes increasing difficult to track the parts and reconcile the interrelationships as the scale increases in size. Managing the architecture for a company of any size is a lot closer to city planning than it is to developing a set of blueprints for a house! Not an impossible task, but one that needs to be undertaken with a respect for the complexities and issues of the task.

There is a natural order and an encapsulation hierarchy to the elements in each column of the Architectural Scale diagram, and there are central elements of consistency to their design and development. There is also a symbiosis between them. There is also no specific top or bottom to the conceptual layers. One can easily move to even smaller scales within the architecture of a building, as many legendary architects have done. Examples would include furniture design or the design of specific construction materials created uniquely for use in a particular building. One can also move to larger scales of geography with increasingly larger definitions of the term region. At each level on the way up the elements from the lower levels tend to be used as the building block components in the construction of the higher level structures, so that at the next level we would have systems of regions in what might be termed super-regions.

While there is order to the scale, as we’ve previously stated, there is no requirement to beginning at any particular point in the hierarchy. There are benefits and drawbacks no matter where you start. One of our goals in the development of the tool suite is to recognize these benefits and drawbacks and provide a tool that helps to mitigate the problems of different starting points. Our objective is to allow an architecture description to evolve from multiple points along the hierarchy and coalesce into a reconciled body of knowledge without major disruption, while providing significant utility from even the initial undertaking.

Market

The marketplace audience for (users of) the Enterprise Architecture Tool Suite includes both business and technical persons. The primary business roles the tool suite is envisioned to support include:

• Planners – providing tools for the extrapolation, configuration and initial technical validation of complex, goal-state targets; and the development and evaluation of multi-phase migration plans toward their accomplishment.
• Process engineers – providing a comprehensive database of information concerning process objectives, workflows, materials and constraints; and a suite of modeling and analysis tools to analyze and evaluate approaches to problem resolution or operational enhancement.
• Project managers – providing tools for evaluating complexity and risk and managing scope of work efforts.
• Operations personnel – providing robust specifications for the activities and artifacts of the operating environment, including documentation of rationale and a 360º view of relationships associated with process and materials.
• Auditors – providing forward and backward traceability from requirements to fulfillment.

These roles are not specific to IT systems and development, but are generic and encompass the entirety of the business.

Scope

In Scope

The scope of the Enterprise Architecture Tool Suite is the development and ongoing maintenance of architectural descriptions for enterprises. The tool suite is designed to assist with the tasks of describing, evaluating, documenting, directing and controlling the evolution of an enterprise’s architecture. It is primarily a planning, analysis, modeling and information management tool that focuses on the enterprise in a holistic fashion. It is not an architecture machine. It does not do the design. Rather, it provides tools to assist in the process of engineering the enterprise’s architecture. It also includes a repository to collaboratively maintain and disseminate information about current state, future state, and interim transition architectures.

The business scope for the Enterprise Architecture Tool Suite includes enterprises of all types, regardless of line of business or charter, and all sizes. Key factors in sizing the tools to the audience include the following factors:

• Finding the right conceptualization framework for the enterprise,
• Availability, or development, and configuration of the appropriate industry models to serve as a skeleton framework for the particular line of business to be supported, and
• Configuration of the deployment model (scaling up or down) to be able to match the scale of operation required.

Out of Scope

Software support for the actual operational processes of the enterprise is out of scope. The tools are not meant to be competitive with ERP2 systems. They are envisioned to describe, and potentially interface with, but not to include facilities performing the following types of responsibilities:

• Maintain financial or inventory accounting records and/or perform economic modeling of the business (system of record processing)
• Manage or control the delivery of business transactions (production or asembly line processing, manufacturing, etc.),
• Generate or control the generation of software or other executable methods for performing business transactions (CASE tool),
• Low-level analytics or design functions (BIM, molecular models, comprehensive simulations, etc. as might be found in some of the more sophisticated software suites described in Market Context discussion)

Market Context

There are number of software packages in the enterprise architecture technology marketplace. Figure 2 provides a summary of enterprise architecture tool suppliers that was taken from the Institute For Enterprise Architecture Developments web-site.

Operating Environment