A Simplified Approach to It Architecture with Bpmn: A Coherent Methodology for Modeling Every Level of the Enterprise

By David W. Enstrom

A Simplified Approach to IT Architecture with BPMN: A Coherent Methodology for Modeling Every Level of the Enterprise distills the insights a seasoned IT professional gathered over the course of thirty-five years spent studying, designing, deploying, critiquing, and refining IT architectures. This approach, rooted in models, follows a logical process for creating architectures that can unify IT across every level of the enterprise.

David Enstrom, a published author with education and extensive experience in the field, places the Business Process Model and Notationthe titles BPMNat the heart of the Unified Architecture MethodUAMthat undergirds this works method. The highly structured contents of A Simplified Approach to IT Architecture with BPMN cover an array of topics: the demystification of IT architecture; the description of UAM; how to architect-in IT security; the delineation of Business, Logical, and Technical Perspectives; and the depiction of architectural patterns.

The additions of a bibliography, a glossary, several supplementary sections, and an index supplement the main presentation in A Simplified Approach to IT Architecture with BPMN, rendering it a comprehensive source for IT professionals charged with responsibilities for IT architecture at every level of the enterprise.

• Language: English
• Publisher: iUniverse
• Release date: Apr 14, 2016
• ISBN: 9781491784969

David W. Enstrom

David Enstrom, recently retired after thirty-three years designing and developing information technology, earned a bachelor of science degree in mathematics and engineering from Queen’s University. His specialties include enterprise IT architecture and security, IT strategy design, and architecture process definition. Mr. Enstrom resides in Canada.

Book preview

Copyright © 2016 David W. Enstrom.

All rights reserved. No part of this book may be used or reproduced by any means, graphic, electronic, or mechanical, including photocopying, recording, taping or by any information storage retrieval system without the written permission of the author except in the case of brief quotations embodied in critical articles and reviews.

iUniverse

1663 Liberty Drive

Bloomington, IN 47403

www.iuniverse.com

1-800-Authors (1-800-288-4677)

Because of the dynamic nature of the Internet, any web addresses or links contained in this book may have changed since publication and may no longer be valid. The views expressed in this work are solely those of the author and do not necessarily reflect the views of the publisher, and the publisher hereby disclaims any responsibility for them.

Any people depicted in stock imagery provided by Thinkstock are models,

and such images are being used for illustrative purposes only.

Certain stock imagery © Thinkstock.

ISBN: 978-1-4917-8497-6 (sc)

ISBN: 978-1-4917-8496-9 (e)

Library of Congress Control Number: 2016903795

iUniverse rev. date: 4/14/2016

Contents

About the Author

Acknowledgments

List of Figures

List of Tables

Preface

1 Introduction

1.1 The UAM Approach

1.2 Why UAM?

1.3 Goals of UAM

1.4 Who will benefit from reading this book?

1.5 Structure of the Book

1.6 Abbreviations

1.7 Conventions Used in this Book

2 IT Architecture

2.1 IT Architecture Defined

2.2 Architecture Frameworks

2.3 Why Architect?

2.4 Architecture in the Enterprise

2.5 Unified Architecture Method

3 UAM in Detail

3.1 Introduction

3.2 UAM Architecture Framework

3.3 Conceptual, Logical and Physical Models

3.4 UAM Perspectives, Aspects, and Viewpoints

3.5 UAM Processes

3.6 Architecture Life-cycle

3.7 Architecture Governance

3.8 UAM Roles and Responsibilities

3.9 Hierarchical Models

3.10 Language of UAM

3.11 Key IT Architecture Principles

3.12 Summary of UAM

4 Business Perspective

4.1 Introduction

4.2 Business Perspective Language

4.3 Business Scope

4.4 Business Entity Model

4.5 Business Process Model

4.6 Business Locations Model

4.7 Business Roles Model

4.8 Usage of the Business Perspective

4.9 Business Perspective Language Summary

5 Logical Perspective

5.1 Introduction

5.2 Logical Perspective Language

5.3 Logical Entity Model

5.4 Logical Process Model

5.5 Logical Locations Model

5.6 Logical Roles Model

5.7 Usage of the Logical Perspective

5.8 Logical Perspective Language Summary

6 Technical Perspective

6.1 Technical Perspective Language

6.2 Technical Entity Model

6.3 Technical Process Model

6.4 Technical Locations Model

6.5 Technical Roles Model

6.6 Usage of the Technical Perspective

6.7 Technical Perspective Language Summary

7 Architectural Patterns

7.1 Patterns

7.2 IT Security Pattern Introduction

7.3 IT Security Pattern Problem

7.4 Pattern Applicable Context

7.5 Pattern Constraints

7.6 IT Security Pattern Solution

7.7 Related Patterns

8 Summary and Evolution

8.1 UAM Fundamentals

8.2 Evolution

8.3 Last Words

A. References

B. Glossary

C. Unified Method Architecture (UMA)

Introduction

Method Content

Method Process

D. UAM UML Profiles

Introduction

Business Perspective

Business Entity Viewpoint

Business Process Viewpoint

Business Locations Viewpoint

Business Roles Viewpoint

Logical Perspective

Technical Perspective

E. Example UAM Architectures

Introduction

Enterprise Architecture

IT Research Business Line Architecture

Distribute Research Business Domain Architecture

IT Research Network Simple Architecture

Apple® is a Registered Trade Mark of Apple Inc.

iPod® is a Registered Trade Mark of Apple Inc.

iTunes® is a Registered Trade Mark of Apple Inc.

IBM® is a Registered Trade Mark of International Business Machines Corp.

Rational® is a Registered Trade Mark of International Business Machines Corp.

Expedia® is a Registered Trade Mark of Expedia Inc.

ITIL® is a Registered Trade Mark of AXELOS Limited.

OMG® is a registered trademark of Object Management Group, Inc.

UML® is a registered trademark of Object Management Group, Inc.

MDA® is a registered trademark of Object Management Group, Inc.

Model Driven Architecture® is a registered trademark of Object Management Group, Inc.

Microsoft® is a registered trademark of Microsoft, Inc.

Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc.

BPMN™ is a trademark of Object Management Group, Inc.

Business Process Modeling Notation™ is a trademark of Object Management Group, Inc.

Business Process Modeling Language™ is a trademark of Object Management Group, Inc.

Google™ is a trademark of Google, Inc.

Model Based Development™ is a trademark of Object Management Group, Inc.

Model Driven Systems™ is a trademark of Object Management Group, Inc.

MOF™ is a trademark of Object Management Group, Inc.

The Zachman Framework™ is a trademark of Zachman International, Inc.

Permission to reproduce Figures 2 and 5 from ISO 42010 was provided by Standards Council of Canada. No further reproduction is permitted without prior written approval from Standards Council of Canada.

Links are provided to Internet web sites for informational purposes only; they do not constitute an endorsement or an approval of any of the products, services, or opinions of the corporation or organization or individual. These links were accurate as of the publication date of this book.

001_c_mel.tif           001_b_mel.tif

OMG and BPMN are either registered trademarks or trademarks of Object Management Group, Inc. in the United States and/or other countries.

Dedication

I would like to acknowledge, in appreciation, my late manager Malcolm MacArthur who, as CIO at the time, created the new position of Enterprise IT Architect. Malcolm had the vision and foresight to define this position, and gave me the support needed to make it happen. My new assignment, starting in 1994, was a challenge indeed. Because of its mandate, the organization needs to be at the leading edge of technology, and these were early days for the discipline. A number of training opportunities were open to me, however. This training, as well as extensive on-the-job experience including previous work as a developer, systems architect, project manager (both small and large projects), and as an operations manager, made the creation of the approach and concepts presented in this book possible.

About the Author

Mr. David Enstrom, after receiving a Bachelor of Science with Honours (Mathematics and Engineering) from Queen’s University in 1974, acquired thirty-three years of experience in leading edge information technology design and development with the Communications Security Establishment (CSE) in Ottawa, Canada. His specialties are enterprise architecture, enterprise IT security architecture, IT strategy definition, and architecture process definition, which were his main occupations from 1994 through to 2007 when he retired.

He has extensive experience in IT projects, IT project management, logical data modeling, and IT architecture. Mr. Enstrom was also involved, while at the CSE, with partner relations, participating in many ongoing technology planning, standards definitions, and implementation activities. Mr. Enstrom retired from CSE on June 29th, 2007, and is now providing Enterprise Architecture and IT security consulting services.

David lives in Canada with his wife Lise. His many interests and hobbies include sailing, golf, skiing, classical guitar, and photography.

Mr. Enstrom authored or co-authored the following papers:

Enstrom, David, Hossendoust, Siavosh, Walsh, D’Arcy, 2007, ‘A Reference Model for Enterprise Security – High Assurance Enterprise Security’, ICEIS 2007 Proceedings.

Enstrom, David, Hossendoust, Siavosh, 2008, ‘Business Driven Risk Assessment – A Methodical Approach to Risk Assessment and Business Investment’, ICEIS 2008 Proceedings.

Enstrom, David, Walsh, D’Arcy, 2009, A Rigorous Approach to IT Architecture, Proceedings of the Forty Third Annual Hawaii International Conference on System Sciences (HICSS-43), 10 pages, CD-ROM, IEEE Computer Society, January 2010.

Acknowledgments

The author gratefully acknowledges Janice Nurski for her input and editorial review of the main content of the book.

He also gratefully acknowledges his wife Lise who contributed valuable input on business process modeling.

List of Figures

Figure 1 – Building Components used to Describe the Architecture

Figure 2 – Business Lines, Divisions, and Domains

Figure 3 – ISO 42010 Conceptual Model of Architecture Description

Figure 4 – ISO 42010 Concept of Architecture Framework

Figure 5 – The Zachman Framework

Figure 6 – Architecture Viewpoint Languages

Figure 7 – Business Level Planning Artifacts and UAM

Figure 8 – Architecture Context, Layers, and Fractals

Figure 9 – Inter-enterprise IT Architecture

Figure 10 – Enterprise UAM Context and Relationships

Figure 11 – UAM Inputs and Outputs

Figure 12 – UAM Framework

Figure 13 – Compound Lens Representation of Views

Figure 14 – Fractal Concept of IT Architectures

Figure 15 – Relationships between UAM Perspectives and the Environment

Figure 16 – Ullman’s Triangle

Figure 17 – Concepts and Language, Models and Specifications

Figure 18 – UAM IT Architecture Capability Pattern

Figure 19 – UAM Life-cycle

Figure 20 – Define UAM Architectures

Figure 21 – Using UAM Architectures

Figure 22 – Maintaining UAM Models

Figure 23 – Framework for Defining Governance

Figure 24 – Architectural Decision Governance Process

Figure 25 – IT Architecture Governance, Pre-Project

Figure 26 – IT Architecture Governance, IT Projects

Figure 27 – IT Architecture Governance, IT Evolution

Figure 28 – Perspective Stakeholders and Specialists

Figure 29 – Aspect Stakeholders and Specialists

Figure 30 – Standards Used in UAM

Figure 31 – Business Perspective Viewpoints

Figure 32 – High-Level Business Perspective Language Overview

Figure 33 – Business Context Diagram Example

Figure 34 – Simple Business Entity Model

Figure 35 – Detailed Business Entity Model

Figure 36 – Business Functions vs. Business Processes

Figure 37 – Business Process Model Example

Figure 38 – Final Business Process Model at the Logical Level

Figure 39 – Process Diagram for Individual Check-in

Figure 40 – Business Process Model with Data Objects

Figure 41 – High-level Business Locations Model

Figure 42 – Business Location Model Detail

Figure 43 – Business Actors and Activities at a Check-in Counter

Figure 44 – Business Roles Model Showing Actors and Roles

Figure 45 – User and Manual Activities Identified

Figure 46 – Business Perspective Language Summary

Figure 47 – Logical Perspective Viewpoints

Figure 48 – High Level View of the Logical Perspective Language

Figure 49 – Simple Logical Entity Model Example

Figure 50 – Logical Entity State Diagram

Figure 51 – Logical Process Model Example

Figure 52 – Logical Process Model with Data Objects and Lanes

Figure 53 – Airline Check-in Example with Sub-system Lanes

Figure 54 – Top Level Logical Locations Model

Figure 55 – More Detailed View of the Headquarters Location

Figure 56 – People vs. Actors vs. Roles

Figure 57 – User, Actor, Role, and Activity UML Model

Figure 58 – Logical Roles Model with Actor and Roles Structure

Figure 59 – Logical Roles Model, Activities with Roles

Figure 60 – Logical Perspective Language Summary

Figure 61 – Technical Perspective Viewpoints

Figure 62 – High-Level View of the Technical Perspective Language

Figure 63 – Simple Technical Entity Model Example

Figure 64 – Technical Entity State Diagram

Figure 65 – Technical Process Model Example

Figure 66 – Technical Process Model Sub-system Details

Figure 67 – Top Level Technical Locations Model

Figure 68 – Detailed View of the Headquarters Technical Location

Figure 69 – Technical Detail in a Locations Model

Figure 70 – Technical Roles Model

Figure 71 – Users and their Roles

Figure 72 – Technical Perspective Language Summary

Figure 73 – Defense in Depth

Figure 74 – Protected Object Model

Figure 75 – Roles and Zone Model

Figure 76 – Static Identity Model

Figure 77 – Dynamic Identity Model

Figure 78 – Authority and Policy Model

Figure 79 – Types of Policy Enforcement Points

Figure 80 – Simple Concept of Access Control

Figure 81 – Static Access Control Model

Figure 82 – Dynamic Model of Access Control

Figure 83 – Static Model of Audit

Figure 84 – Dynamic Model of Audit

Figure 85 – Dynamic Access Control Sequence Diagram in a Domain Context

Figure 86 – Dynamic Access Control Sequence Diagram Showing the Application Portion

Figure 87 – Complete IT Security Reference Model

Figure 88 – UMA Separation of Content and Process within a Method

Figure 89 – Business Perspective Language Overview in UML

Figure 90 – Business Entity Viewpoint Language

Figure 91 – Business Process Viewpoint Language

Figure 92 – Business Locations Viewpoint Language

Figure 93 – Business Roles Viewpoint Language

Figure 94 – Logical Perspective Language (metamodel) Overview in UML

Figure 95 – Technical Perspective Language Overview in UML

Figure 96 – EA Context Diagram

Figure 97 – EA Business Entities Model

Figure 98 – EA Business Process Model for IT Research Business Line

Figure 99 – EA BPM for IT Research, Gather and Analyze Information

Figure 100 – EA Business Locations Model

Figure 101 – EA Business Roles Model Showing Customer Types

Figure 102 – EA BRM Showing IT Research Roles in Context

Figure 103 – EA Logical Entity Model for IT Research

Figure 104 – EA Logical Process Model for Gather and Analyze Information

Figure 105 – EA Logical Locations Model, Headquarters

Figure 106 – EA Logical Locations Model, Core Zone

Figure 107 – EA Logical Roles Model, IT Research

Figure 108 – EA TPM, Data Gathering

Figure 109 – EA Technical Locations Model, the Backbone Network

Figure 110 – IT Research BL Context

Figure 111 – IT Research BL Business Process Model, Perform Lab Study

Figure 112 – IT Research BL Logical Entity Model

Figure 113 – IT Research BL Logical Entity Model, Research Report

Figure 114 – IT Research BL LPM, Gather and Analyze Information as-is Model

Figure 115 – IT Research BL LPM, Gather and Analyze Information to-be Model

Figure 116 – IT Research BL LPM, Perform Lab Study

Figure 117 – IT Research BL LPM, Lab Study Roles Detail

Figure 118 – IT Research BL LRM, IT Research Roles Model

Figure 119 – IT Research BL TPM, Analyze Information

Figure 120 – IT Research BL TPM, Prepare Report

Figure 121 – IT Research BL TPM, Perform Lab Study

Figure 122 – IT Research BL TLM, Backbone Network

Figure 123 – IT Research BL TLM, Distribute Research Zone

Figure 124 – IT Research BL TLM, Distribute Research Applications Server

Figure 125 – IT Research BL TRM, IT Research

Figure 126 – Distribute Research BD LLM, Domain PEP

Figure 127 – Distribute Research BD Technical Process Model

Figure 128 – Distribute Research BD TPM, Distribute Reports

Figure 129 – Distribute Research BD TPM, Send Reports / Notifications

Figure 130 – IT Research Network Architecture TLM, Network Backbone

Figure 131 – IT Research Network Architecture, Domain PEP

Figure 132 – IT Research Network Architecture, Import Data Network Zone

Figure 133 – IT Research Network Architecture, IT Research Desktops Network Zone

List of Tables

Table 1 – Architectural Decisions vs. Design Decisions

Table 2 – Business Perspective Stakeholders and Concerns

Table 3 – Business Perspective Language Elements Summary

Table 4 – Logical Perspective Stakeholders and Concerns

Table 5 – Logical vs. Physical Data Models

Table 6 – Logical Perspective Language Summary

Table 7 – Technical Perspective Stakeholders and Concerns

Table 8 – Technical Perspective Language Summary

Preface

Beginnings

One of my first managers always said that computer science and software engineering were misnomers. His view was that there was no science involved in computer science, and definitely not engineering. Others have had this view as well, notably Michael Davis (Davis 2011, 32), and only recently has some of the science in computer science been described and acknowledged (Denning 2013, 35). This struck a chord with me and I wondered for many years why so many information technology (IT) projects fail, why we spend sometimes millions of dollars only to end up with systems that either did not work properly or do not meet requirements, or both. In fact, I spent the rest of my career trying to understand the science and engineering of IT with, I hope, some degree of success.

This book is the culmination of more than thirty-five years of experience and study of IT and its application. Its primary objective is to describe a more rigorous approach to IT architecture that brings science and engineering disciplines into the process where possible. The approach is model-based, as is the work in many engineering disciplines, and follows a well-defined logical process for the creation of these models and other deliverables. The approach also unifies IT architecture—the same IT architecture process and deliverables are applied anywhere within the enterprise (or even across enterprises) with all architecture definitions being useful and relatable.

This naturally requires some discipline on the part of IT architects and developers to ensure that these separate IT architectures remain consistent and compatible; therefore, clear definitions of techniques and deliverables along with a methodology for their development is needed—the Unified Architecture Method (UAM) described in this book. The complete methodology is published in the form of a web site, and is available online:

www.unified-am.com

Now some background on information technology, how it has evolved, and some key definitions that aid in understanding the reasons for the structure and approach to IT architecture as defined in the UAM.

Evolution of IT Development

Information technology, as it is now known, is a comparatively young field. Electronic computing began in the 1940s, but the use of computers for business purposes did not happen in earnest until the 1960s. The programmability of computers evolved along with the hardware, with high-level languages becoming the norm.

Hardware and software systems became more and more complex over time. To deal with this complexity a number of tools and techniques were developed, such as:

265173.png High-level languages;

265173.png Standard algorithms such as Quicksort;

265173.png Object-oriented languages;

265173.png Structured programming;

265173.png Multi-user, multi-tasking operating systems;

265173.png Commercial software such as VisiCalc and Microsoft Word;

265173.png Entity-relationship diagrams;

265173.png Database design tools.

Many other techniques, algorithms, and tools were developed through the 1980s—then came the Internet and pervasive networking. Not only were home computers connected to the Internet, businesses used networking to advantage internally and externally, along with all of the standard office tools and software, such as:

265173.png Web browsers;

265173.png E-mail;

265173.png Workflow;

265173.png Powerful desktops with a set of integrated applications;

265173.png Newsgroups, blogs, and other information sharing tools;

265173.png Distributed, grid, and cloud computing.

The advent of network-based computing dramatically changed IT forever. Systems are now connected at all layers, from network connectivity at the physical and transport layers to peer-to-peer interactions at the application layer, and everything in-between. These layers and connectivity have substantially increased the level of complexity and the size of interconnected systems since the 1960s.

How does this relatively rapid evolution of IT in recent years, this Computing Revolution, compare to the Industrial Revolution? Can we learn anything from this comparison? Most definitely, with the principle areas being:

265173.png The difficulty in discovering and developing appropriate science and engineering disciplines;

265173.png The time needed to mature tools, techniques, and implementation approaches; and,

265173.png The underlying discipline required to rigorously define and develop proper solutions.

The Industrial Revolution had a profound effect upon business and industry, which is mirrored in many ways in the current Computing Revolution. A comparison of the two provides further insights into IT and the tools and techniques that are important for its use and exploitation.

Industrial Revolution vs. Computer Revolution

The Industrial Revolution, which started in the eighteenth century, was marked by a period of rapid change to many industrial processes. These include, among others, farming, manufacturing, and transportation. The period of the revolution is up for debate but is generally agreed that it lasted from about 1760 until about 1940. The Industrial Revolution did not reach fruition until the widespread introduction of electricity and the electric motor in the late 1800s and industry was further revolutionized by the assembly-line concept for factories, and other improvements, in the twentieth century. Therefore, one could argue that the Industrial Revolution took 150 to 200 years to reach a refined state of maturity—maturity of techniques, processes, tools, and technology (Encyclopædia Britannica, Inc. 1988, 304).

What tools and techniques enabled the continued advancements during the Industrial Revolution? In a nutshell those provided by science and engineering. Many engineering disciplines originated and were refined during this period, most notably chemical engineering, electrical engineering, civil engineering, and mechanical engineering (Encyclopædia Britannica, Inc. 1988, 305). The development and maturing of these disciplines, in essence, captured the knowledge of materials, chemistry, tools, and techniques in a way that made them accessible and useful for the next wave of engineers. This body of knowledge was continually refined and built upon to the point where the engineering approach to problems was developed. These engineering disciplines and the associate bodies of knowledge were fully recognized and utilized.

On the other hand, the Computing Revolution, being only about 60 to 70 years old should be viewed as being quite immature in terms of techniques, tools, and technology. Compared to the Industrial Revolution time lines, the Computing Revolution is in the early stages of development of the techniques needed to provide improved solutions for the information age. What further parallels can be drawn with the Industrial Revolution?

As noted, the huge success and impact of the Industrial Revolution resulted from the capture and refinement of knowledge, as well as the development of a disciplined engineering approach. This permitted the design and implementation of more and more complex and refined industrial processes and solutions, with very high assurance of success. The use of and dependence upon science and mathematics was very important.

Similar steps were taken in the Computer Revolution with the refinement of techniques, processes, tools, and technology. But what needs to happen is the emergence of a disciplined approach similar to the engineering approaches developed during the Industrial Revolution. Some would argue that the Computer Science or Computer Engineering disciplines fill this void. This is only partially true because more science and engineering is needed.

A mathematical foundation is an important characteristic of engineering disciplines. Mathematics was used to validate designs and to develop new proven approaches, resulting in a reduction of risk and very high success rates. Some mathematical rigor is used in IT development, but a greater acceptance of the need for rigor and a more consistent, disciplined approach to problems and the definition of solutions are required.

For example, when deciding on the solution to the construction of a new bridge, three basic steps are involved, with engineering being an important part of each step. First, requirements are defined agreed such as location, number of lanes, and design constraints (e.g., no piers in the water and the clear space required above the water). Engineering is needed at this stage to ensure the requirements definitions include all aspects and constraints needed in the next steps. The design team then takes the functional requirements and design constraints and develops the conceptual design followed by detailed design and working drawings. Finally a construction team implements the solution based upon the detailed design and working drawings, but under the scrutiny of the requirements engineer and design engineer.

What refinements are required in the IT context to arrive at a more rigorous and successful approach similar to this civil engineering example? In the industrial context nothing happens until a clear and formal agreement is obtained on the requirements and the overall concept and approach. This is followed by preliminary and then detailed design and engineering, with approvals being obtained all along the way. This all happens regardless of the context and size of the project. A lot of work is done prior to breaking ground. Therefore, in the IT context a similar rigorous process is needed, regardless of the context and size of the project—a high-level design or architecture is required, regardless of the system development approach used. This is what UAM does for IT architecture and design. It defines the approach (i.e., the methodology) and the tools and techniques (i.e., the viewpoints and modeling languages) required for a more rigorous definition of solutions.

Architecture vs. Engineering

A final important question is what is architecture vs. engineering? In the IT context, where are each of these disciplines applied, or are they slightly different in the IT context versus the industrial context? Let us examine how form and function help to differentiate them. We begin with formulating precise definitions of architecture and engineering.

Architecture is the art or science of building (Oxford University 1976, 49), but in the IT context it should be extended to include and discipline of creating an actual plan of any complex information object or system. ISO 42010 defines architecture as the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution (ISO 2011, 2). Note that architecture involves the definition of the complete system. Therefore, by implication, the context and scope of the system in question is very important. Encyclopædia Britannica defines it as the art and technique of building as distinguished from skills associated with construction (Encyclopædia Britannica, Inc. 1988, 530). Therefore, architecture is a design discipline that concerns itself with aesthetics as well as utilitarian considerations—architecture is the balance of form and function in meeting the requirements. This should not be confused with the debatable form follows function principle prevalent in twentieth century building architecture, where the shape and structure of a building is primarily based upon its function, and where in the extreme decoration on buildings is outlawed (Encyclopædia Britannica, Inc. 1988, 50).

Engineering is the application of scientific principles to the optimal conversion of natural resources into structures, machines, products, systems, and processes for the benefit of mankind (Encyclopædia Britannica, Inc. 1988, 496). Scientific principles refers to the rigor involved in the engineering discipline, which includes mathematics, chemistry, and material sciences, among many others. Each engineering discipline has an associated great body of special knowledge (Encyclopædia Britannica, Inc. 1988, 496). In summary, engineering is the application of a large body of specialized knowledge along with scientific principles to develop a solution to the practical problem at hand that will be both economical and safe. Engineering has a very strong emphasis on function and takes a scientific approach. It is viewed as a more specific definition of design that is very close to implementation. Therefore, engineering is a design discipline that concerns itself mostly with utilitarian considerations backed by scientific principles—function is the key.

Which discipline is best applied in the context of IT systems? Both—an overall plan (architecture) is definitely required, especially for large IT systems or new IT systems, but engineering rigor is required in order to achieve the desired result in an efficient and cost effective manner with some assurance of success. Because of engineering rigor, airplanes, bridges, buildings, and other engineered solutions very rarely fail. The same cannot be said of IT solutions. They often cost too much, fail when put into operation, and are often costly to keep operating. IT architecture is needed, along with engineering, to address these ongoing issues. Add in the problem of growing complexity and it becomes very clear that a more rigorous approach to IT is needed.

Given this overview of engineering and architecture, can we clarify their definitions and application in the IT context? IT architecture defines the overall concept and plan through the application of an architectural approach, and carries on until rigorous designs are needed, then IT engineering becomes the main focus. Depending upon the context of the work, a lot or little overlap of the activities exists between these two disciplines. IT engineering, where a great body of knowledge and scientific principles are used to detail IT solutions, requires further exploration and details defined; however, that is a topic for another book. This book describes a concept for IT architecture and the definition of models in any context within the enterprise, with the IT architect’s involvement reduced when IT engineering (detailed technical design) begins.

One could argue that IT architecture, as defined, is part of IT engineering, especially since in the industrial context engineering is applied from concept to construction. However, architecture is applicable in many situations, where form is often as important as function—where conceptual and functional blocks (e.g., rooms, stairs, doors, etc.) are arranged to address requirements. In IT these conceptual and functional blocks (or components) are things such as applications, processes, data, storage, servers, and networks. Therefore, architecting these components is a very important part of defining IT solutions. Thus, architecture is the definition of a plan for components (form) that are almost arbitrarily arranged to solve a given requirement. For example, consider the number of different kinds buildings in the world, all defined using the same building blocks; or the many IT systems that provide the same functionality but have very different architectures.

Architecture is about balancing form and function, the two are distinguishable but not separable—they are closely related and influence each other. The following definition for IT architecture is an extension (extensions in italics) of the definition of architecture in ISO 42010 (ISO 2011, 2).

IT Architecture is the fundamental concepts or properties and organization of a system in its environment (i.e., in context) embodied in its elements that are almost arbitrarily arranged, their relationships, and in the principles guiding its design and evolution—defining the form (of elements) is the main objective, but balancing form and function is key.

On the other hand, engineering is more restrictive, and generally starts after the architecture is defined (i.e., the component parts of a bridge, and their relationships, are defined); therefore, one engineers a bridge or a building after its architecture is described. Engineering is defined as follows:

Engineering is a more restrictive design activity where the components and their relationships are already defined (i.e., the architecture is defined) and now scientific rigor and precision is applied to ensure success—function is key.

UAM

The main lesson from the Industrial Revolution is that IT is at a very early stage of development. Therefore, a lot of knowledge about how to solve problems in this domain is yet to be discovered, but that a disciplined engineering approach will move us in the right direction. This knowledge, and the associated processes and supporting science and mathematics, needs to be captured and made available to practitioners and built upon over time. The end goal is a more rigorous, repeatable, and successful approach to the definition and implementation of IT solutions. IT architecture is very important since a balance is needed between the form and function of the components involved—selecting the required set of components and specifying their relationships is an important first step.

The complexity and interdependence of today’s IT environments demands that we use more rigor and discipline, similar to the disciplines now used in industrial design and engineering. UAM describes a disciplined approach for developing, using, and maintaining IT architectures, and is a first step in capturing an IT knowledge base.

A well-defined methodology is very important in order to be successful in defining IT solutions. Examples are also useful for both the new practitioner as well as seasoned veterans, to ensure that the methodology is well understood and consistently applied. This book and the UAM methodology, which includes example architectures, provide this complete understanding of the approach and its application.

1.1 The UAM Approach

The Unified Architecture Method (UAM) incorporates science and technology in the discipline of defining IT architectures and provides the rigorous approach needed in competitive business environments. It supports the definition of architectures necessary for understanding today’s complex IT systems, and provides assurance that requirements will be met and that the system operates properly, while being cost-effective.

The UAM methodology itself is fully defined using the Unified Method Architecture (UMA) notation and language, a technique developed by IBM for creating methodologies and supporting material (i.e., processes, guidance, references, templates, etc.). UAM includes detailed example architectures to illustrate the modeling languages and their use within architectures. The methodology description was created using IBM’s Rational Method Composer tool and is published separately online.

265076.png Simplified version of the UAM methodology and example architectures on the Internet:

UAM Online: