REVIEW OF CURRENT IT ARCHITECTURE BLUEPRINT MODELS

Mark Skilton
Feb 4, 2005
25 min read

(ENTERPRISE, SOLUTION AND BUSINESS ARCHITECTURES)

1 Principles of Enterprise Architecture

1.1 Architecture Taxonomy

Architecture can be described in a series of levels from an organizational scope and business systems orientation. There are many different terms and schemas developed by different IT Vendors and service providers but the following diagram provides some of the major types:

Figure 1 Architecture Taxonomy[1] - Scope

These are different to Architectural viewpoints which can encompass: Business Architecture, Integration Architecture, Application Architecture, Operational Architecture, and Development Architecture. Architectural viewpoints are typically captured in Models.

Principally the differences in taxonomy are the Level at which the Architecture addresses the business strategy and IT estate. Enterprise Architecture is a Framework that encompasses the business and IT strategy completely. Specific levels below this encompass IT Architectures to meet different levels of granularity in the business system design. Typically this is the software engineering views covering the following commonly used differentiation:

Figure 2 Architecture Taxonomy – Abstraction views

1.2 The future state of enterprise architecture

Development of Business Models has progressed further in recent years from the late 80’s and 90’s Business process reengineering and Object design methods.

With the advent of Internet and new media technologies in the late 90’s and the subsequent fall-out and realignment of the IT industry towards these new technologies; business strategies and architecture services have had to evolve to take into account these new business operating methods.

IT Architecture models and business models have needed to evolve to show how new channels and technologies can be used and deployed. Most visual and well known in this area has been in bundling and web services models (Hagel, 2001, 2002)[2].

As a result e-Business Model ontologies and taxonomies have and are still evolving in this area of business and systems strategy development. These models have challenged the traditional Business value models (Porter and Miller, 1985) and attempt to reconnect business transformation techniques (Hammer, 1995) with the underpinning technologies.

With the emergence of BPM (Smith and Fingar, 2002) and Object based development tools such as executable UML/ MDA concepts; this has further developed the idea of reusable and component commodity based IT services and technologies (Carr, 2003).

Enterprise Architecture models need to take account different technologies and business strategies. A range of business systems models can be developed using value based multi-channel Models to Framework based Model views of organizations and IT assets. Underpinning these can be existing and new IDEs and Modeling methods and tools to define and deploy Model views of channels, business scenarios and IT technology components and platforms.

Figure 3 Architectural Ontologies

At the core of strategic development is the alignment of capabilities with customer needs[3]. Business models need to address this link between the architectural capability of the organization and the meeting of the target market needs in the industry setting.

Figure 4 Capability Ontology

Equally creating business models must be done in the context of the industry dynamics the organization must compete in; without this a business model is murky and can create faulty thinking and self-delusion (Porter 2001, structural problems in capital markets Quinn-Mills 2001). And example of industry dynamics is shown below.

Figure 5 Industrial Dynamics

The link of industry revenue and behavioural drivers and IT strategy in a robust Enterprise Model can aid visualization of strategy and capabilities; greatly helping organizations in focusing on core competencies and leveraging technology for competitive advantage.

Mark Skilton, January 2005 1.3 Enterprise Architecture Principles

The definition of an architecture used in ANSI/IEEE Std 1471-2000 is:

"the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution."

The following list are a collection of Architectural Governance Principles under the following topics:

Business Transformation
Critical Choices for the right Architecture
Relationships between cells – Validation, verification, visualization, value

Business Transformation

An enterprise architecture (EA) is a conceptual tool that assists organizations with the understanding of their own structure and the way they work. It provides a map of the enterprise and is a route planner for business and technology change. (Microsoft 2005)

Normally an enterprise architecture takes the form of a comprehensive set of cohesive models that describe the structure and the functions of an enterprise. Important uses of it are in systematic IT planning and architecting, and in enhanced decision making.

The individual models in an EA are arranged in a logical manner, and this provides an ever-increasing level of detail about the enterprise, including:

Its objectives and goals.
Its processes and organization.
Its systems and data.
The technology used.

To optimize IT environments, businesses should adopt the best practice of making explicit links between enterprise strategy and policies for IT governance, paying particular attention to IT architecture (Gartner 2005).

Process design; Application development and enterprise architecture are often seen as adversaries. However, many benefits can be obtained from their cooperation.

Enterprise architecture is critical for business service providers like BT that are heavily IT Product based. To deliver these products it is essential to better align their technology investments with business strategies and processes.

Federated Enterprise Architectures are necessary to identify what the organizational boundaries and structure need to focus on. Corporate Enterprise Architecture, Business Unit and Line of Business Architectures need to identify different levels of detail but align to ensure the application platforms beneath are aligned with local and central governance.

Enterprise architecture deals with large amounts of diverse information that must somehow be organized, navigated and displayed. A growing tools market can support these architecture needs.

BT have tools in place to maintain Business process and Application design models. What is needed is a framework that enables them to be managed and exploited meaningfully.

This is essential to laying the ground for future needs with a flexible and interoperable enterprise architecture. The lessons of history show leaving this to individual programmes can result in suboptimal designs.

Enterprise architecture creates a bridge between business goals and IT investment. The alignment of IT and business goals is the road map for sustained enterprise-value creation.

The new enterprise architecture focuses on the management of loosely coupled components, the origin of which is both within and beyond the enterprise. This architecture provides the underpinnings for the real-time enterprise.

Patterns influence how architecture components deliver system capabilities to the business. Understand the definitions of and distinctions among patterns and how they can strengthen your enterprise architecture.

Current Enterprise architectures don’t support the dynamic new way of doing business. It requires an organisational model and IT Infrastructure that is flexible, agile and able to react quickly to changes in the marketplace. New Enterprise architecture needs to have a set of frameworks, guidelines, tools , methodologies and governance to facilitate collaboration within and between enterprises to build the capabilities and new relationships with partners and customers that are needed.

To develop management commitment to enterprise architecture, IT leaders must know whose support is required and then answer the question, "What's in it for them?"

Enterprise architecture can stifle creativity or it can foster innovation and growth. Keys to promoting flexibility -- and thus enablement of innovation -- are recommended.

As business transformation drives the adoption of new enterprise architectures, the operations architecture must perform the dual role of striving for stability and fostering agility.

Achieving multi-channel integration, which can driver greater efficiency and cost reduction, requires the centralized design and implementation of an enterprise architecture. This needs to work on three levels: Legacy development; new programme development and the overarching enterprise architecture vision and governance.

The “Town Planning Scenario” Architecture for application integration differs from intra-application architecture, just as planning for a city differs from a building architecture. The success of enterprise architecture depends on responding to differences in scope.

COTs Strategy optimization.

Increases in componentry and openness in packaged application architecture belies a “mega-vendor” agenda for greater architecture ownership and customer lock-in.

Critical choices

An IT architecture is a series of principles, guidelines, models, standards and rules that guide an organization through acquiring, building, modifying, and the interfacing of IT resources throughout the enterprise. (Boar, 1999)

With the migration to distributed-computing environments, an IT architecture most importantly defines and demonstrates the interoperability, scalability, and portability of applications and their subcomponents across the architecture. Architecture must preserve the IT investment as underlying technologies evolve. (Boar, 1999)

IT resources include hardware equipment, software, communication protocols, application development methodologies, database systems, modelling tools, IT Organisational structures, data and more.

Choice of models and guidelines that will work in the political climate

Good communications and process of follow-through to ensure architecture compliance.

Architecture framework choice is critical to governing the community’s understanding of what is meant by an IT architecture. It must precisely define what is meant when you say enterprise architecture. This must include:

Standards of the cell (the EA framework) contents
This is the defined standards on design and development of business and systems models.
Cell completion responsibilities
It is important to define how the cells are completed in a non-redundant, coherent and integrated manner. This requires careful decisions about horizontal and vertical partitioning of the contents of each cell across responsible organisational entities.
Cell delivery coordination
This requires global configuration management process to permit periodic baselining of the architecture
Architecture governance evolutions

Architecture needs to be defined in two dimensions

Corporate, Business Unit (LOB) and application Family (Platform)
This is to refer and represent the strategy at different levels of the organisation
AS-IS and TO-BE
This is to provide a TRANSITION plan from the current Architecture to the future architecture.

Skills of architecture

Capturing, attributing ownership and managing the most-important architectural artefacts.

Issue is ensuring the Deployment of the architecture succeed on two levels

Aligned with the strategy

Strategy is able to direct the programmes

Its critical to ensure the strategy Model and basis for the business strategy and processes is aligned.

Relationships between dimensions – validation, verification, visualisation, value

Many of the Frameworks while comprehensive do not show how the underlying models RELATE to one another. This is a key point in be able to verify and confirm the architecture; and has implications for alignment and delivery of the architecture. Analysing the relationships between objects, tasks, roles and artefacts across the lifecycle and organisation is a key requirement in to major areas

Configuration management
Alignment with business process / strategy
Verification of design models with development models (Application automation)

CHOICE of modelling tools and Methodologies (UML, RUP, executable UML, BPM etc) is essential to building a robust Model framework to underpin the architecture. This then needs to extend across both business process and systems and organisational boundaries through architecture governance.

Interactive Development – the case for component and modular phasing

Benefits

Accommodates changing requirements
Integration is not one “big bang” at the end of the project
Early iterations expose risk
Management can make tactical changes to the product
It facilitates reuse
You can find and correct defects over several iterations
It facilitates better use of project personnel
Team members learn along the way
You can refine the development process along the way

Four steps to moving from waterfall to iterative development

Build functional prototypes early

Technical risk – existing application development
Develop a Architecture Prototype
Technical risk – a new application development
Develop a Functional Prototype

Divide the detailed design, implementation and test phases into iterations

Two approaches:
Develop one or more subsystems at a time
Develop the most critical scenarios first

Baseline an executable architecture early on

The functionality is the core of the application, or it exercises key interfaces
Choose use cases describing functionality that must be delivered
Choose use cases describing functionality for an area of the architecture not covered by another critical use case

Adopt an iterative and risk-driven management process

RUP has Inception, elaboration, construction, transition.

2 Models

The overall definition for an architecture is preferably done by selecting an architectural framework to define the contents and boundaries of the architecture.

There are many popular architecture frameworks which while broadly similar have clear and distinct features. Common features include:

A model is defined by a set of dimensions expressing its scope and relationships
Most models have an IT and an organisational dimension to show the range of IT that applied to specific organisational areas. This embraces the concept of layers of architecture from Corporate architecture; Business Unit architecture through to LOB and specific application platform area. This also illustrates th technical and the non-technical or socio-political and economic aspects of architecture strategy

[1] See Microsoft .NET Architecture Centre Web site for a typical example. http://msdn.microsoft.com/architecture/default.aspx

[2] See reference Value Creation from e-Business models, Wendy Currie, 2004 Elsevier Butterworth Heinemann

[3] Wallin. J 2000. Operationalising Competences. International Conference on Competence-Based Management, Helsinki, Finland

2.1 Index Model

The index model is a 16-cell definition of what embraces an enterprise architecture. The Source identified is CSC (See reference 1) but this may be an earlier model of the Catalyst framework.

Figure 6 Index Model

The cell dimensions are:

Infrastructure
Denotes the technical infrastructure of the IT assets. This includes communication networks, software, and hardware.
Data
Denotes the data assets of the business. This includes data and database definitions
Applications
Denotes the business applications that are used to run the business. These applications are built on the infrastructure and use the data from the prior rows
Organisation
Denotes organisation and people issues that enable the IT environment. This includes items such as the IT organisational structure, processes, core competencies, and human resource policies.

Inventory
Defines the IT assets currently available to the business, such as the as-is inventory
Principles
Defines overarching rules and guidelines that are used to guide decision making and motivate collaboration across the IT community.
Models
Defines diagrams, blueprints, or other forms of schematics that are used to express and illustrate the contents of the row
Standards
Defines agreed upon standards and processes that are used in executing each row.

2.2 Zachman Framework

Figure 7 Zachman Model- detail

The Zachman Model is a 36 cell definition model for enterprise IT architecture. The Zachman Model has Time and Motivation columns that are nonexistent in the Index and Gartner Models but can be found in the Process of the catalyst Framework.

2.3 Gartner 40 Cell Model

Figure 8 Gartner Group Model

The Gartner Group Model is a 40 cell model. It breaks the Index Infrastructure row into: Service, Facilities, Platform and Network.

2.4 EAB Model

This methodology focuses on the Models for the infrastructure and Application cells. The Model developed by Boar (See References 1.) contends that the infrastructure and applications are the most critical to enabling manoeuvrability. Infrastructure and application models must be defined in a rigorous blueprinting methodology and managed through structured configuration management. The following Index model illustrates the focus of EAB.

Figure 9 EAB Enterprise Architecture Blueprint

The Boar model is an Enterprise Architecture Blueprint drawing system for Infrastructure and application models.

2.5 4+1 Architecture

Figure 10 4+1 Architecture

The 4+1 Architecture is a well known set of views principally based around models.

The main dimensions can be matched to a similar set of views found in the Rational Unified Process RUP framework. RUP framework defines Logical as Structural View; Process as Behavioural view; Development as Implementation View and Physical as Environment view. The RUP methodology has principally 4 phases of lifecycle: Inception, elaboration, construction and Transition.

The following table adapts the RUP framework to illustrate the 4+1 Architecture model concepts.

Figure 11 UML 1.5 Models used in RUP / 4+1 Architecture views

Figure [if supportFields]> SEQ Figure \* ARABIC <![endif]12[if supportFields]><![endif] Phasing example for RUP Models over RUP lifecycle

2.6 Catalyst Framework Methodology - CSC

CATALYST Methodology Framework is the current CSC ToolKit. It is an American based development with an emphasis on Business Transformation and is services oriented in its definition of component tasks.

Figure 13 Catalyst Toolkit

Figure 14 Catalyst - Architecture Framework

Architecture is seen as a Sub-phase within the overall Catalyst Framework.

The architecture framework is made up of THREE tiers of elements:

Tier 1 – Overarching Framework
EA Enterprise Architecture
Discover
Tier 2 – Major Types of Architectural Design
Accelerated BAA
Business Area Architecture (BAA)
System Architecture (SAR)
Tier 3 – Specific tools and techniques
PES – Package evaluation & Selection
LST – Legacy Systems Transformations
OCM – Organisational Change Mobilisation (applicable to all 3 tiers)
TID – Technical Infrastructure Design
FRV – Facilities Infrastructure
SEC – IT Security

Figure 15 Catalyst Framework with Enterprise Architecture

The enterprise Architecture approach is described in the following conceptual diagram. This describes the architecture as both business oriented and IT oriented as each must align and complement the other to achieve true business transformation.

Figure 16 Domains of Change - Enterprise Architecture

Architecture Framework – all the Parts

Architecture

Enterprise Architecture
Discover
Process Enablement
C4D – catalyst 4D
Accelerated Business Area Architecture XBA
XAD – Accelerated Application Development
PBD – Packaged based Development
PES – Package Evaluation & Selection
ICD – Iterative Custom Development
Business Area Architecture
IAD – Incremental Application Development
RBM – Release-based Maintenance
LST – Legacy Systems Transformation
Organisational Change
OCM – Organisational Change Mobilisation
System Architecture (SAR)
Technical Infrastructure
TID – Technical Infrastructure Design
Facilities Infrastructure
FRV Facilities Requirements Verification
IT Security
SEC – IT Security

Summary of Architecture Sections

Enterprise Architecture
Enterprise Architecture Is covered in more detail next section.
Discover
Outlined in the C4D guide below. Also includes a Data warehousing version
Process Enablement
C4D – catalyst 4D
Project Stages: Discover, Design, Development, Deploy
Business System Development Concepts
Modeling what the Business does
Business Tasks
Logical Business tasks (LBTs)
Elementary Business Processes (EBPs)
Reusing Logical Business tasks
When Process is involved
Business Events
Business Threads
Business Areas and Process Groups
Roles
Location Types
Workflow management
Use cases, scenarios and Test cases
Modeling what the System does
Designing Business Tasks
System Business Services (SBSs)
Service Catalogue
Designing and developing the System
Designing User Interfaces
Designing Content
Designing components
Designing Technical Infrastructure
Designing the Business Solution
Component Concepts
Service-component associations
Object Concepts
Encapsulation
Inheritance
Polymorphism
User Experience Design
Client design and useability
Prototyping
Storyboarding
Iterative prototyping
Content Development
Information Business Model
Content Catalogue
Content Sources and owners
Content Development
Navigation versus content structure
Quality and Management concepts
Testing
Performance Engineering
Project management
Configuration Management
Accelerated Business Area Architecture XBA
XAD – Accelerated Application Development
Contains summary elements of the wider methodology. The model views are still maintained in principle.
PBD – Packaged based Development
PES – Package Evaluation & Selection
ICD – Iterative Custom Development
Business Area Architecture
Contains all the model views as described in the Enterprise Architecture.
IAD – Incremental Application Development
RBM – Release-based Maintenance
LST – Legacy Systems Transformation
Organisational Change
OCM – Organisational Change Mobilisation
System Architecture (SAR)
This subphase is typically used in large complex systems design
The SAR covers
The System Concept (SYC) component
The System Requirements (SYR) component
The System Design (SYD) component
Verification and Validation in Catalyst is terms used that are consistent with the International Organisation for Standardisation (ISO) and International Electrotechnical Commission (IEC) definitions.
The Model Views described in the Enterprise Architecture cover this.
Technical Infrastructure
TID – Technical Infrastructure Design
Facilities Infrastructure
FRV Facilities Requirements Verification
IT Security
SEC – IT Security

EA Enterprise Architecture Components

Figure 17 Enterprise Architecture Components

An example is give of how these Enterprise Architecture components are deployed into a Web site System Design

Figure 18 Web Site Enterprise Architecture Design Example

The Enterprise Architecture Components are described by a set of Model Views:

Business Model View

Business Direction Model
This describes the future-state vision of how the enterprise will do business. It analyses the strategy of the business, including the principles, constraints, assumptions , mission , business objectives , specific strategies, and strategic imperatives. It covers business vision and accompanying case for action. Finally, this model identifies the key business policies and rules that govern the choices for business change
Business Principles, constraints and assumptions
Mission Statement
Business Objectives
Specific strategies
Strategic imperatives
Business Strategy Framework
Leverage Model
Identifies and prioritise the primary process groups and critical activities related to initiatives strategic imperatives and/or business objectives
Business Capability
These are defined in the language of the business, as what is needed to implement strategic imperatives. E.g. a strategic imperative is to “strengthen key global markets”. One business capability to support this imperative can be “provide customer and market intelligence”
IT Capability
These are the high-level IT Capabilities that are needed in order to enable the business capabilities
Initiative / Process Priorities Map
Balanced Scorecard
Key Business Policies
Business Rule Model
Business Rule Standards and Conventions
Business Rule Groups
Business Rules
Governing rule
Operating rule
Technical rule
Executable rule
Business Rules Comparison
Key Business Performance Factors
Enterprise Context Diagram
Describes a conceptual view of the external entities with which the enterprise interacts
Business Process Model

Figure 19 Enterprise Context Diagram

Enterprise Concept of Operations
Conceptual Flow Diagram
Enterprise Context Diagram
Customer and User Needs Summary
Customer and Needs / Process matrix
Business Diagnostic Model
Identifies the important characteristics of the business that need to be identified as areas for improvement or change.
Business Segments profile
Products and Services Profile
Customer Profile
Supplier profile
Business Forces Summary
Financial Profile
Business Transformation Model (LST)
Identifies the key business policies and rules that govern the choices for business change
Business transformation Principles, constraints and Assumptions (LST)
Transformation Vision (LST)
Legacy Transformation Strategy (LST)
Asset Retirement Strategy (LST)
Asset Development Strategy (LST)
Asset Reuse Strategy (LST)

Systems Engineering Model View

This describes how business and information systems are organized to be designed, built, deployed, and supported by implementation projects. Systems Engineering addresses all six domains of change and comprises of the following models
Systems Engineering Direction Model
Systems Engineering Diagnostic Model
System Engineering Conceptual Model
System Engineering Logical Model
Performance Engineering Model
Systems Engineering Direction Model
Systems Engineering Principles, constraints and assumptions
Systems Development Principles, constraints, and assumptions
Service Level Principles, constraints and assumptions
Security and Privacy Principles, constraints and assumptions
System management Principles, constraints and assumptions
System operations and performance principles, constraints and assumptions
Standards Profile
Enterprise standards
Enterprise Conventions
Information Dictionary
Requirements Model
Enterprise Requirements
Traceability Matrices
Systems Engineering Diagnostic Model
Existing Systems Inventory
Component and Deployment Diagrams (UML)
System Engineering Conceptual Model
The Enterprise Architecture has the following overall components:
Current (As-Built) Enterprise Architecture
Enterprise transition strategy
Enterprise Transition Strategy
Release Architecture
Target Enterprise Architecture
Standards Profile
Information Dictionary

Figure 20 Enterprise Architecture

Figure 21 Enterprise Architecture Logical and Conceptual Model

The Systems Engineering Logical Model is used to define the Current (As-Built) Enterprise Architecture. The Systems Engineering Conceptual Model is used to describe the future requirements. The following Table above illustrates this relationship
System Engineering Logical Model
The Current (As-Built) Enterprise Architecture is described using the following Diagnostic models
Organizational Diagnostic Model
Organizational Profile
Location Diagnostic Model
Location Inventory
Location Profile
Technology Diagnostic Model
Technology Inventory
Technology Inventory
Technology Profile
Technology Maturity Assessment
Technology / process Map
Technology Diagnostic Findings
Data Diagnostic Model
Database Inventory
Data Profile
Data Diagnostic Findings
Application Diagnostic Model
Application Inventory
Application Portfolio Profile
Application / Process Map
Application Sharing Analysis
Application Diagnostic Findings
Systems Engineering Diagnostic Model
Existing System Inventory
The Target Enterprise Architecture consists of the following components
Enterprise Business Architecture
Enterprise Information System Architecture
Enterprise Business Architecture EBA has the following components
Enterprise Business process Architecture
Conceptual Business Function Hierarchy
Conceptual Business Function Definitions
Conceptual Business Process Hierarchy (future) with primary process groups and major processes
Conceptual Business Process Definitions (future)
Process Flow Diagrams and process maps
Process Thread Performance Model (current state, future state)
Process / technology capability Matrix
Technology Capability Definitions
Business Process / Security and Privacy Needs
Enterprise Organisation Architecture
Organisation Direct Model
Organisational purpose and scope
Future state Organisation Design
Conceptual Organisational Model
Conceptual Organisational Chart (future State)
Conceptual Decision Making Chart (future state)
Process / Organisation Matrix
Organisation / Location Matrix
Enterprise Location Architecture
Location Type Definitions
Process / Location Type Matrix
Logical Location Specification (optional)
Business Rule Model
Business Rule Standards and Conventions
Business Rule Groups
Business Rules
Business Rules Comparison
Key Business Performance factors

Figure 22 Enterprise Business Architecture Component Definitions

Enterprise Information Systems Architecture EISA Components
Enterprise Information Systems Architecture Diagram(s)
Information Systems
System Interfaces
Enterprise Information System Security Architecture
Security Mechanism Allocation Model
Security Processing Threads
Security Risk Summary Assessment
Enterprise Information System Management Architecture
Enterprise Application Architecture
Application Area Map
Application Architecture Diagram
Application Definitions
Application Architecture Approaches
Application Distribution Scheme
Enterprise Common Services
Enterprise Data Architecture
Conceptual Data Architecture Diagram(s)
Conceptual Data Model
Process / Data Matrix
Database Definitions
Enterprise Technology Architecture
Technology insertion Strategy
Key Technical Performance factors
Performance Engineering Model, including process Threads
Disaster Recovery Strategy and Disaster Recovery Architecture
Conceptual Technical Model
Technical Reference Model
Technology Capability Definitions
Process / Technology Capability Matrix
Technical Concept Diagram
WAN Concept Diagram and LAN concept Diagrams
Conceptual Node definitions and Conceptual Link Definitions
Enterprise Location Architecture
Enterprise Facilities Architecture

Figure 23 Enterprise Information Systems Architecture Components

Performance Engineering Model
Processing Threads
These are used to demonstrate how software applications and databases are involved in executing a business process scenario. They are also used as a basis for performance modeling.
A Processing thread is a sequence of actions

Business Process Model View

Business Process Direction Model
Business process Principles, constraints and assumptions
Conceptual Business Process Model
Logical Business Process Model
Business Process performance Model
Business Process Transformation Model

Organisational Model View

Organisational Direction Model
Organisational Principles, constraints and assumptions
Organisational Diagnostic Model
Conceptual Organisational Model
Organisational Transformation Model

Location Model View

Location Direction Model
Location Principles, constraints and assumptions
Location Diagnostic Model
Conceptual Location Model
Logical Location Model
Location Transformation Model

Data Model View

Data Direction Model
Data Principles, constraints and assumptions
Data Diagnostic Model
Conceptual Data Model
Data Transformation Model
Process / Data Matrix

Application Model View

Application Direction Model
Application Diagnostic Model
Conceptual Application Model
Logical Application Model
Application transformation Model

Technical Model View

Technology Direction Model
Technology Diagnostic Model
Conceptual technology Model
Logical Technology Model
Technology Transformation Model

Management Work products

Risk Management Work Products
Risk Inventory and Assessment worksheet
Risk Mitigation Plan

Work Product Definitions

Plans
Transformation Plans
Project Management Plan
Programme Management Plan
Other Plans
Reports
Subphase Reports
Enterprise Architecture Report
Enterprise Business Direction
Enterprise business Architecture
Enterprise Information System requirements
Enterprise Information System Architecture Design
Enterprise transition Plan
Enterprise Transition Strategy
Release Architecture
Standards Profile
Information Directory

Assessment of CATALYST Methodology Framework with UML

The Work products definition describes a number of models. These models can be expressed using UML notification where applicable.

It is important to note that Catalyst is not an object oriented framework but a service and contextual syntax framework. Specific Models within the Framework may have object oriented relations to other models within the overall framework but this is not explicitly defined in the components.

The key Conceptual Diagram is:

Figure 24 Enterprise Architecture

This defines the essential elements of the transformation models and core work packages. The Systems Engineering Logical Model is used to define the Current (As-Built) Enterprise Architecture. The Systems Engineering Conceptual Model is used to describe the future requirements.

Systems Engineering Logical Model

Current (As-Built) Enterprise Architecture
Enterprise Business Architecture
Enterprise Information System Architecture

This can use UML to describe this architecture

Systems Engineering Conceptual Model

Target Enterprise Architecture
Enterprise Business Architecture
Enterprise Information System Architecture

This can use UML to describe this architecture

There are a number of VIEWS used in the EA Enterprise Architecture framework

Business Model View

Largely Enterprise strategic models. These may be better defined in Business Process Notation.

Systems Engineering Model View

Most of the as-is and to-be models can be defined using UML.

Business Process Model View

This is a Business Process model view

Organisational Model View

This is an Organisational Design view

Location Model View

A location view

Data Model View

Conceptual and Logical data model view and transformations

Application Model View

Conceptual and Logical Application view

Technical Model View

Conceptual and Logical technology models view

There are associated Management and reporting work products that use the above.

In the other elements of the Architecture Framework

C4D
Contains concepts that cover Business Process design and Service-based systems design
Both can be supported by UML
Use cases for Business design
Other system UML models for systems design
XBA
A rapid deployment version of EA with selected models of EA
BAA
The fully EA
Systems Architecture (SAR)
Focus on technology Architecture with selected models of the EA.

2.7 Microsoft Enterprise Architecture

Four general perspectives are important and are commonly used. These are the business, application, information, and technology perspectives.

While all are covered a more direct focus is made on Application and Technology Architecture and patterns as illustrated in this diagram. This includes levels of abstraction from Conceptual, logical, physical and implementation views:

Figure 25 Microsoft Application and technology Architecture Model

An overview of the four perspectives are:

The business perspective

The business perspective describes how a business works. It includes broad business strategies along with plans for moving the organization from its current state to an envisaged future state. It will typically include the following:

The enterprise's high-level objectives and goals.
The business processes carried out by the entire enterprise, or a significant portion of the enterprise.
The business functions performed.
Major organizational structures.
The relationships between these elements.

The application perspective

The application perspective defines the enterprise's application portfolio and is application-centered. This view will typically include:

Descriptions of automated services that support the business processes.
Descriptions of the interaction and interdependencies (interfaces) of the organization's application systems.

Plans for developing new applications and revising old applications based on the enterprises objectives, goals, and evolving technology platforms.

The application perspective may represent cross-organization services, information, and functionality, linking users of different skills and job functions in order to achieve common business objectives.

The information perspective

The information perspective describes what the organization needs to know to run its business processes and operations. It includes:

Standard data models.
Data management policies.
Descriptions of the patterns of information production and consumption in the organization.

The information perspective also describes how data is bound into the work flow, including structured data stores such as databases, and unstructured data stores such as documents, spreadsheets, and presentations that exist throughout the organization.

The technology perspective

The technology perspective lays out the hardware and software supporting the organization. It includes, but is not limited to:

Desktop and server hardware.
Operating systems.
Network connectivity components.
Printers.
Modems.

2.8 ‘Triple pair’ Process Flow Model

The basic concept

Figure 26 Triple Pair Model

The concept applied to direct to customer supply chain:

Figure 27 Direct to Customer concept

Example

Figure 28 Basic triple pair flow structure of direct-to-customer model

Tapscot et al (2000) developed a Value Map for depicting B-Web operations.

This moved the triple pair concept further.

The Value Map concept is defined in the e3 Ontology further and the Value Proposition Models (See these sections.)

All key classes of participants (partners, customer, suppliers)
Value exchanges (Tangible, intangible benefits and knowledge)

Figure 29 Value Map taxonomy for Business Models (Tapscott et al 2000)

2.9 eBusiness Value Model

A core change in business modelling with eBusiness has been the development of class object models and abstraction ontologies for services and resources (The “unbundling of the corporation” Hagell III and Singer 2000).

Figure 30 Value Proposition

Value Proposition
The statement of benefits that are delivered by the firm to its external constituencies
Is the overall view of a firm’s bundle of products and services that together represent a value for the specific Customer Segment.

This can be elaborated on by the Distribution channel – Market Acquisition Model

Figure 31 Distribution Channel

The offering is delivered via the distribution channel. This can be expressed generically by defining the distribution channel as a Relationship and mechanism.

Figure 32 Customer Equity and relationship

The general expression of this is: in order for a firm to provide its VALUE PROPOSION it has to dispose of a set of CAPABILITY (IES)

Figure 33 Value Proposition and Activities

CAPABILITIES can be described as repeatable patterns of action in the use of assets to create, produce, and/or offer products and services to the market, (Wallin 2000). These CAPABILITIES depend on the assets or resources of the firm (Bagchi & Tulskie 2000) and increasingly they are outsourced to partners, while using eBusiness technologies to maintain the tight integration that is needed to run the firm efficiently. In other word, IT has made it economically more feasible to “unbundle” and otusource capabilities and resources that do not belong to their core competencies (HagellI and Singer 2000).

Partnership is a hybrid form of the relationship ontology.

Figure 34 Partnership

Weill & Vitale (2001) developed a eBusiness Model Schematic for analysing e-business initiatives.

Participants
Firms of interest, customers, suppliers and allies
Relationships
Either electronic or primary relationships
Flows
Money, information, product or service flows

Figure 35 e-Business Model schematics (Weill & Vitale 2001)

2.10 e3- value ontology Model

This is a object based view of business value. It has three viewpoints:

Global Actor viewpoint shows
Actors involved in eBusiness idea
Objects of economic value
Objects of value
Objects offered in combination
Phenomena, such as consumer needs, that cause exchanges of objects between actors
Detailed actor viewpoint shows
Partnerships
Constellations of actors
Expressions of the global actor viewpoint
Value activity viewpoint shows
Value creating or adding activities and their assignments to actors

Figure 36 e3 Value Ontology Global Actor Viewpoint

Actor
Composite Actor
Groups value interfaces of other actors
Also, a composite actor has its own value interfaces to its environment
These enable abstracted views of actors
These can act as “portals” to relationships to actors
Elementary actor
Does not contain value interface s of other actors
It’s the lowest decomposition
Value Object
Actors exchange value objects
Value Port
An actor uses a value port to provide or request value objects to and from his/her environment
Value Offering
Value offering models what an actor offers to (an out-going offering) or requests from (an in-going offering) his/her environment, and closely relates to the value interface concept.
Value Interface
Models an offering of an actor to his/her environment, and the offering such an actor request in return from his/her environment.
Actors have one or more value interfaces
Value exchange
Is used to connect two value ports with each other. It represents one or more potential trades of value objects between value ports.
Value transaction
A value interface prescribes the value exchanges that should occur.
Transactions can be between multiple actors

Figure 37 e3 value Ontology Detailed Actor Viewpoint

Figure 38 e3 Ontology Value Activity Viewpoint

2.11 Post 2000 Business Strategy Model

Hamel (2000)

Figure 39 Components of Business Models (Hamel 2000)

Osterwalder & Pigneur (2002) focus on Business Model components as four main pillars that the business model needs to address:

Product innovation
Customer Relationship
Infrastructure Management
Financials

Figure 40 4 Pillars of Business Model Ontology (Osterwalder & Pigneur 2002)

Evolaris’s / Petrovic 2001 view of Business Model

Value Model
Resource Model
Production Model
Customer Relations Model
Revenue Model
Capital Model
Market Model

Rappa (2001) view based on Revenue source and position of firm in the value chain

Brokerage Model
Advertising model
Informediary Model
Merchant Model
Manufacturer Model
Affiliate Model
Community Model
Subscription Model
Utility Model

Linder & Cantrell (2000) Business Model taxonomy

Pricing Models
Buying club
One-stop shop, low price shopping
Fee for advertising
Razor and blade
Convenience Models
One-stop, convenient shopping
Comprehensive offering
Instant Gratification
Commodity-Plus Models
Low-price reliable commodity
Mass customised commodity
Service-wrapped commodity
Experience Models
Experience selling
Cool brands
Channel Models
Channel maximisation
Quality selling
Value-added reseller
Intermediary Models
Market aggregation
Open market-making
Multi-party market aggregation
Trust Models
Trusted operations
Trusted product leadership
Trusted service leadership
Innovation Models
Incompatible products
Incompatible services
Breakthrough markets

Note: The above Linder & Centrell model is borrowed by the Accenture Institute for Strategic change analysis on operating business models.

Accenture Institute for Strategic Change 2000-2001 defined the following components of a Business Model. This covered a collection of various models into the following list. They stated that word “business model” is often used to mean a variant of things. A business model can be a viewpoint of a complete ontology of dimensions.

Pricing Model
Revenue Model
Channel Model
Commerce process Model
Internet-enabled commerce relationship
Organisational form
Value Proposition

2.12 Post 2000 eBusiness Strategy Model

Weil & Vitale (2001) eBusiness Model – decomposes into 4 levels.

Level 1 Atomic Business Model
Strategic Objectives
Sources of revenue
Critical success factors
Core competencies necessary for implementation
Level 2 e-Business Model
Roles and Relationships among a firm’s customers, allies and suppliers
Flows of Products, Information, Money
Major Benefits to Participants – Value Proposition
Level 3 e-Business Initiatives
Customer Segments
Target Audience
Value Proposition to Customer
Channels to those segments
IT infrastructure for Implementation
Level 3-4 Intermediate Level
Position in the industry Value Chain or Net
Organisational form necessary for implementation
Owner of the 3 critical assets (may be different for each critical asset)
Owner of Customer relationships
Owner of Data
Owner of Transaction
Key Information required to succeed
Level 4 e-Business Implementation
Financing
Pricing
Recruitment
Marketing
Incentives

Atomic e-business Models (Weill & Vitale 2001)

Content Provider
Direct to Customer
Full-Service Provider
Intermediary
Shared Infrastructure
Value Net Integrator
Coordinates activities across the value net by gathering, synthesizing, and distributing information
Virtual Community
Whole-of-Enterprise/Government

Applegate (2001) Business Model taxonomy with eBusiness Orientation

Focused Distributor Models
Retailer
Marketplace
Aggregator
Infomediary
Exchange
Portal Models
Horizontal Portals
Vertical Portals
Affinity Portals
Producer Models
Manufacturer
Service Provider
Educator
Advisor
Information and News services
Customer Supplier
Infrastructure Provider Models
Infrastructure Portals

Tapcott et al (2000) Five primary Business webs

Figure 41 Taxonomy of B-Webs along control and Value Integration (Tapscott et al 2000)

Agora (buyers and sells meet freely to negotiate and assign value to goods)
Open Markets
Sell-side Auctions
Buy-side Auctions
Exchanges
Features
Dynamic pricing
Liquidity – converting goods into a desirable price
Aggregation
Retailers
Wholesalers
Features
Selection and convenience
Needs Matching
Value Chain
Features
Process Integration
Supply chain management
Product Design
Alliance
Online Communities
Research Initiatives
Games
Development
Communities
Features
Creative collaboration for a common goal
Rules and Standards
Distributive Network
Data Network operators
Logistics Companies
Banks
Features
Allocation / Distribution
Network Optimisation

2.13 Post 2000 Business Change (Transformation) Strategy Model

Linder & Cantrell (2001) identified types of change models, presented in an increasing degree of transformation / innovation.

Figure 42 Types of Change Models (Linder & Cantrell 2001)

Realisation Models
Exploit potential of current business model
Geographic expansion
Growth of customer base
No substantial changes in operating business models
renewal Models
Revitalising the firm’s product and service platforms, brands, cost structures, and technology bases.
Leverage core skills to create new positions on the price/ value curve
Extension Models
Expand business to cover new markets/ products/ services.
Extend operating business models to include new markets, value chain functions, and product and service lines
Journey Models
Company is takes a totally new business model

Note: This operating framework concept is borrowed in the Accenture Operating Model framework in terms of dimensions of operational distinctiveness.

This is elaborated by the following dimensional lever analysis of change.

Realisation Models
Brand maintenance
Product line extensions
Geographic expansion
Penetration
Incremental product or service line expansion in one-stop shops
Additional sales or service channels
Roll up
Renewal Models
New Service offerings
New Brands
Untouched markets
New retailing formats
Disruptive new product or service platforms
Extension Models
Backward integration
Forward integration
Horizontal integration
Externalising an internal capability
Journey Models
Commoditisation: from product to price
Globalisation
Avoiding commoditisation: from product to service to solution
Up market in products: from price to speed to agility
Up market in services: from price to brand or expertise

Figure 43 Change Model (Linder & Cantrell 2001) Logic changes

Mark Skilton

Feb 2005

Bibliography

Constructing Blueprints for Enterprise IT Architectures, Bernard Boar. Wiley 1999
www.gartner.com Architecture Section Jan 2005
Catalyst Toolkit Download CSC Dec 2004
Zachman Institute 2005 http://www.zifa.com/
Value Creation from e-business model, Wendy Currie 2004, Elsevier Butterworth Heinemann
Wallin. J 2000. Operationalising Competences. International Conference on Competence-Based Management, Helsinki, Finland
A domain area report on Business Models, Adamantia Pateli, PhD Student – Research Officer. November 2002 White paper WHP-2002-02, The eBusiness Centre www.eltrun.gr. Athens University of Economics and Business, Department of Management Science & Technology
Competition and Business Strategy in Historical Perspective, Pankaji Ghemawat Havard Business School. Spring 2002
Changing Business Models: Surveying the landscape, Jane Linder, Susan Cantrel, Accenture Institute for Strategic Change May 24 2000