“Simple architecture for complex enterprises” focuses on tackling complexity in IT systems. There are a number of methodologies such as Zachman, TOGAF and EA but they don’t address how to manage complexity. The author shares following concerns when implementing an enterprise architecture:
- Unreliable Enterprise Information – when enterprise cannot access or trust its information
- Untimely Enterprise Information – when reliable information is not available in a timely fashion.
- New Projects Underway – when building a new complex IT project without understanding its relationship to the business processes.
- New Companies Being Acquired
- Enterprise Wants to Spin Off Unit
- Need to Identify Outsourcing Opportunities
- Regulatory Requirements
- Need to Automate Relationships with Internal Partners
- Need to Automate Relationships with Customers
- Poor Relationship Between IT and Business Units
- Poor Interoperability of IT Systems
- IT Systems Unmanageable – when IT systems are built piecemeal and patched together.
The author defines enterprise architecture as:
“An enterprise architecture is a description of the goals of an organization, how these goals are realized by business processes, and how these business processes can be better served through technology.”
The author asserts need for planning when building enterprise IT systems and argues that complexity hinders success of these systems and cites several examples from Government and business industries. The author defines the Zachman framework for organizing architecture artifacts and design documents. John Zachman proposed six descriptive foci: data, function, network, people, time and motivation in the framework.
The author explains that Zachman framework does not address complexity of the systems. Next, author explains TOGAF (The Open Group Achitecture Framework) that has four categories:
- Business architecture – business processes
- Application architecture
- Data architecture
- Technical architecture – hardware / software infrastructure
TOGAF defines ADM (Architecture Development Method) as a recipe for creating architecture. The author considers TOGAF as a process instead of framework that can complement Zachman. TOGAF defines following levels of enterprise continuum:
- enterprise continuum
- foundation architectures
- common system architectures
- industry architectures
- organization architectures (ADM)
TOGAF defines knowledge bases such as TRM (Technical Reference Model) and SIB (Standards Information Base). The ADM defines following phases:
- Phase: Prelim – framework and principles
- Phase: A – architecture vision (statement of architecture work, architecture vision)
- Phase: B – business architecture (input frame stakeholders to get baseline and business objectives)
- Phase: C – information system architectures (baseline data architecture, review principles, models, data architecture)
- Phase: D – technology architecture – infrastructure
- Phase: E – opportunities and solutions
- Phase: F – migration planning
- Phase: G – implementation governance
- Phase: H – architecture change management and then it goes back to Phase A.
TOGAF also lacks complexity management and the author then explains The Federal Enterprise Architecture (FEA) that includes reference models for business, service, components, technical and data. FEA organizes EA into segments of business functionality and enterprise services. FEA creates five reference models:
- The Business Reference Model (BRM) – business view
- The Component Reference Model (CRM)
- The Technical Reference Model (TRM)
- The Data Reference Model
- The Performance Reference Model
In chapter two, the author explains how complexity affects system, e.g. a Rubik Cube of 2 x 2 x 2 dimensions has 8 interior cubes and 3.7 x 10^6 permutations but a Rubik Cube of 4 x 4 x 4 dimensions has 64 interior cubes and 7.4 x 10^45 permutations. The relative complexity of 4 x 4 x 4 dimensions Rubik Cube is much higher than Rubik Cube of 2 x 2 x 2 dimensions and the author argues that by partitioning 4 x 4 x 4 Rubik Cube into eight 2 x 2 x 2 Rubik Cube, you can lower its complexity. The author defines following five laws of partitions:
- Partitions must be true partitions
- Partition definitions must be appropriate (e.g. organizing clothing store by color may not be helpful to customers)
- Partition subset numbers must be appropriate
- Partition subset sizes must be roughly equal
- Subset interactions must be minimal and well defined
Further, author suggests simplification to reduce complexity when partitioning by removing partition subsets along with their associated items and removal of other items from one or more partition subsets, leaving the subsets themselves in place. The process of partitioning can be done iteratively by choosing one of the partition subsets and simplifying it. The author narrates story of Jon Boyd who came with the iterative process: observe, orient, plan, act (OOPA) when he was observing how pilots used aircrafts in dogfights at the Air Force. Also, he observed that faster you iterate on OOPA, better your chances of winning the dogfight.
In chapter three, the author shows how mathematics can be used for partitioning. He describes the number of system states as the best measure of complexity and relative complexity of two systems is ratio of the number of states in those systems. For example, a system with two variables, each taking six states can take 6^2 states. i.e,
C = S^v where C is the complexity, V is the number of variables and S is the number of significant states on average.
In business process, the number of paths and decision points within each path is the best measure of complexity, i.e.,
O = P^d where D is the number of decision points and P is the number of paths for each decision points and O is outcome.
The author introduces concept of homomorphism where observing one system make prediction on another system, e.g. relationships between dice systems, software systems and business processes as homomorphic. A system with two six-sided dice has 36 possible states (P^d or 6^2). However, we can reduce number of states by dividing dices into multiple buckets, e.g. two dices with each bucket has 12 states instead of 36. The general formula for the number of states of B buckets with D dices and F faces per dice:
B * F^d
This chapter describes concept of equivalence relations with following properties:
- E(a, a) – always true — reflexivity
- E(a, b) implies E(b, a) — symmetry
- E(a, b) and E(b, c) implies E(a, c) — transitivity
In chapter four, the author explains simple iterative partitions (SIP) to create a diagrammatic overview of the enterprise system that focus on what enterprise does (as opposed to how). The SIP starts with an autonomous business capability (ABC) that represents an equivalence class or one of the set that make up the partition. The ABC model includes process component and technology component including relationships for implementation and deployment. In addition to implementation and deployment, author adds ABC type that is used as a category of ABC such as human resources. These types can also be defined in hierarchical fashion and different implementations of same ABC types are considered siblings. The implementations can also be composed so that one ABC is part of another ABC. Another type of relationship is partner relationships at implementation or deployment levels where one ABC may create information request, information broadcast or work request.
In chapter five, author explains SIP process that has following goals:
- Complexity control
- Logic-based decisions
- Value-driven deliverables
- Reproducible results
- Verifiable architectures
- Flexible methodology
The SIP process consists of following six primary phases:
<------Preliminary------> <--------------Preparatory-------------------> <------Iteration------> Phase-0 Phase-1 Phase-2 Phase-3 Phase-4 Phase-5 Evaluation Preparation Partitioning Simplification Prioritization Iteration
The phase-0 (enterprise architecture evaluation) addresses following issue:
- Unreliable enterprise information
- Untimely enterprise information
- New complex projects underway
- New companies being acquired
- Enterprise wants to spin off unit
- Need to identify outsourcing opportunities
- Regulatory requirements
- Need to automate relationships with external partners
- Need to automate relationships with customers
- Poor relationships between IT and business units
- Poor interoperability of IT systems
- IT systems unmanageable
The phase-1 (SIP preparation) has following deliverables:
- Audit of organizational readiness
- Training
- Governance model
- SIP blend
- Enterprise-specific tools
The phase-2 (partitioning) decomposes enterprise into ABC (discrete autonomous business capability) units. The phase-3 (partition simplification) defines five laws of partitions:
- Partitions must be true partitions
- Partition definitions must be appropriate
- Partition numbers must be appropriate
- Partition sizes must be roughly equal
- Partition interactions must be minimal and well defined.
The phase-4 (ABC prioritization) uses value graph analysis to estimate potential payoff and risk. The value graph analysis addresses following factors:
- Market drivers
- Cost
- Organizational risk
- Technical risk
- Financial value
- Organizational preparedness
- Team readiness
- Status quo
The phase-5 (ABC iteration) uses iterative approach to simplify architecture.
The chapter six describes NPfit project as a case study in complexity. The NPfit promised integrated system connecting every patient, physician, laboratory, pharmacy and healthcare in the UK. Its infrastructure provided new national network, directory services, care records service (CRS). NPfit is split into five regional groups of patients and it allowed appointment to any facility, prescription fulfillment, and picture archiving. Despite huge budget of $9.8 billion dollars, there were several concerns such as failure to communicate, monolithic approach, stifling of innovation, lack of record confidentiality and quality of shared data. The SIP approach would have helped, e.g. phase-1 audits organizational readiness, training and partitioning. The phase-2 would have addressed complexity dropped multiple regional implementations. The phase-3 would have simplified partitions into subsets such as patient registration, appointment booking, prescriptions, patient records, and lab tests.
The chapter seven focuses on guarding boundaries in technical boundaries. For example two systems may communicate via RPC, shared databases or data access layer but it suggests service-oriented-architecture (SOA) for interoperability for better scalability. The author suggests use of guards or envoy entity for handling outgoing or incoming messages to the system. It defines following rules to encapsulate the software for a given ABC:
- Autonomy
- Explicit boundaries
- Partitioning of functionality
- Dependencies defined by policy
- Asynchronicity
- Partitioning of data
- No cross-fortress transactions
- Single-point security
- Inside trust
- Keep it simple
The chapter eight summarizes the book and it explains why complexity is the real enemy and how simplicity pays. It reiterates how SIP architecture can simplify architecture by partitioning system into ABC units.