EATS Product Concept

Technical Strategy

The genesis of the Enterprise Architecture Tool Suite, depicted in Figure 3, is a fusion of three major disciplines:

• Management Science – the discipline of using mathematics and other analytical methods in a practical form to analyze and address business problems,
• Architecture - the art and science of designing synergistic structures in a manner which achieves utility, durability, and delight to its users.
• Systems Engineering - An interdisciplinary approach to the application of engineering principles to the solution of systems problems. A system in this context is not limited to computer systems, but includes any combination of components with a need to function collectively for a unified purpose.

In the Architected Futures’ tool suite our focus is to provide an integrated software product the merges the theory and practical aspects of these three disciplines and provides the enabling tools to bring this merged capability to focus on the management and operation of modern, information intensive enterprises. Our strategy for doing this is depicted as a flow model in Figure 4 and shown as a UML package diagram in Figure 5.

Figure 3Conceptual Genesis – Business Domain

Our approach starts with the development of a unique, core execution engine and analysis product that derives its specification and conceptual design from the three disciplines identified earlier: Management Science, Architecture and System Engineering. The core concept is that these three disciplines define core competencies that we want to enable in the tool suite for application across all lines of business. These include methodologies, standards and best practices for management, design and engineering that are applicable across all industries. In addition, the core product framework derives a baseline layer of its enterprise information models, operations workflows and analytical processes from non-industry specific, general business models that are applicable across most, or large cross sections of, enterprises. This consolidated set of information and processes make up the AF Core Model framework.

Figure 4Concept Model – Business Domain

The AF Core Model defines a functional framework that can be used to define, document, analyze and evaluate enterprise architecture. However, it is not designed to be directly used at this level. Instead this is designed as the foundation layer of a multi-layered architecture for the tool suite.

The next layer of the tool suite architecture is to tailor the tools, primarily by extending the metamodel and tailoring the metamodel rules to incorporate one or more industry or practice area models. These can include both general and specialized practice area models and multiple models might be used to define the activities of a single enterprise, depending on what that enterprise’s mission and business plan might be. This accomplishes two goals:

1. It creates a clear separation of content, structure and behavior concerning the information, function and technology that is globally applicable to all users of the tool suite, and those portions that may only be applicable to focused groups of users.
2. It begins the extension and tailoring process of creating a well engineered architectural definition for the user enterprise using industry-based profiles and patterns of behavior. These profiles represent core structural patterns defining the structure and behavior of enterprises operating in these segments. These patterns provide both a basis for comparison of other entities operating in the same practice areas and a structural skeleton for the further definition of each enterprise’s unique architecture.

After incorporating one or more practice area models into the tool suite, the next step in the approach is to extend the architecture knowledge-base and personalize it for the specific enterprise as an industry application. Layering this as a distinct and separate layer on a practice area model framework allows the knowledge-base to better support the evaluation of alternative enterprise architectures that may be applicable and measure them against a common baseline. It also provides a self-check evaluation tool that supports the development of completeness measures of the enterprise architecture, and its documentation, against the functions and features of the declared industry baseline.

Figure 5Concept Model Package Diagram – Business Domain

The final layer of the architecture, as developed using this approach, is the definition of functional area architectures within the context of the enterprise architecture. If desired, or as needed, external practice area or industry models may be brought in to this layer as well. However, the primary focus at this layer would typically be the description of the unique manner in which the enterprise conducts its activities, whether that is through policy, product or delivery factors.

Principles

Key principles governing the architecture for the Enterprise Architecture Tool Suite include:

• Ease of use – the tools need to be easy to understand and use. To the extent possible, fluency in special languages and formal logic associated with specific methodologies should not be a requirement to gain productive utility from the tools. Assistance needs to be provided with respect to the capture of specifications so that minimal new data is required to be captured in order to make productive use of the tool suite and the associated information base.
• Evolutionary development – captured content should be able to be reused or extended over time.  The information set of the tool should represent an expanding knowledge-base over time and the tool suite should have features to promote re-use, including traceability over time.
• Integration – different tools used in different parts of the suite for different purposes that involve the specification or analysis of common objects should be able to reuse information about the object and correlate their views and specifications. Multiple views and uses of common elements should be used to enhance the quality of the knowledge-base content, rather than act as an impediment to use.
• Collaborative – the tool suite needs to provide mechanisms for the collaborative development and management of its content. The use of the tool should enhance and promote collaboration and information sharing among its users.
• Dynamic – the tool suite needs to be build using an open architecture such that new tools can easily be added to the suite without the requirement for significant re-engineering. When and where possible, the implementation or addition of new (previously unused tools) should be able to be accomplished with a requirement for upgrade of core processing modules.
• Auditable – there needs to be complete and verifiable audit trail relative to the origin and modification history of all content. [blockchain]
• Data quality – the tools need to provide automated assistance to the process of verification of the retained content. To the extent the tool suite and associated content become useful, the content will grow. To retain value and usefulness users must be able to have confidence in the content and ascertain its quality. As the content grows the relationships between content elements grows geometrically. It would be difficult, if not impossible, for human users to be able to ascertain the quality level of existing content without automated assistance.
• Open, flexible interfaces – the tools suite needs to be able to export or import data from or to related external entities using standard interfaces and protocols. Both repository content management and modeling facilities should be extensible with user developed facilities. Direct importing and exporting of machine readable information from/to external automated systems will support ease of use and data quality, reduce the cost of operation and enhance the utility of the tool suite.