Pragmatic Enterprise Architecture

Strategies to Transform Information Systems in the Era of Big Data

James Luisi

• Publisher: Morgan Kaufmann
• Year: 2014
• Print ISBN: 9780128002056
• eBook ISBN: 9780128005026
• Topic: Business
• Subtopic: Business Intelligence
• Index: Business

Pragmatic Enterprise Architecture is a practical hands-on instruction manual for enterprise architects. This book prepares you to better engage IT, management, and business users by equipping you with the tools and knowledge you need to address the most common enterprise architecture challenges. You will come away with a pragmatic understanding of and approach to enterprise architecture and actionable ideas to transform your enterprise. Experienced enterprise architect James V. Luisi generously shares life cycle architectures, transaction path analysis frameworks, and more so you can save time, energy, and resources on your next big project. As an enterprise architect, you must have relatable frameworks and excellent communication skills to do your job. You must actively engage and support a large enterprise involving a hundred architectural disciplines with a modest number of subject matter experts across business, information systems, control systems, and operations architecture. They must achieve their mission using the influence of ideas and business benefits expressed in simple terms so that any audience can understand what to do and why. Pragmatic Enterprise Architecture gives you the tools to accomplish your goals in less time with fewer resources. - Expand your Enterprise Architecture skills so you can do more in less time with less money with the priceless tips presented - Understand the cost of creating new Enterprise Architecture disciplines and contrast those costs to letting them go unmanaged - Includes 10 life cycle architectures so that you can properly assess the ROI of performing activities such as outsourcing, insourcing, restructuring, mergers and acquisitions, and more - Complete appendix of eight transaction path analysis frameworks provide DBA guidelines for proper physical database design

Part I

Introduction

Abstract

This part sets the stage for the reader with some interesting observations during the evolution of automation that help put the rest of the book in context, beginning with one of the last large companies to adopt automation. We then get a glimpse into the challenges that automation created as it solved competitive challenges of handling a greater volume of business with less expense from labor. As with any form of modernization, as some problems are solved with advancements in technology, new problems emerge, and manifest themselves, occasionally overwhelming the organizations that failed to foresee or recognize these problems as they grew unchecked at their source. In fact, even today, many organizations leave the source of their problems unchecked by making attempting to remediate the symptoms with additional manual labor.

Keywords

Type of architecture

architecture

forms of standardization

reusable structures

accumulation of knowledge

relationships among components

taxonomy

symbology

senses

personal computers

midrange computers

laptops

smartphones

smart tablets

business-minded

business strategy

business vision

pet projects

pain points

ROI

business benefit

control

architectural challenges

acquisitions

mergers

shadow IT

lack of IT standards

nonstandard processes

competitive business

process improvement

component reuse

punch cards

inconsistent components

automation landscape

Big Data

open source

metrics

customer experience metrics

operational metrics

automated metrics collection

understanding ones' data

business glossary

business dictionary

percent of IT budget

informed decision making

business capabilities

layers of business capabilities

disaster recovery

complexity

understanding IT

number systems

written language

mechanical age

mental activities

fundamental principles

architectural disciplines

mindset of engineers

varieties of automation systems

control systems

information systems

mechanical equipment

virtual world control system

virtual control system

artificial intelligence

games

intangible

differences in error handling

error handling

process-oriented focus

differences in data and testing

sensory I/O devices

test bed

financial differences

mindset

customers

degrees of separation

enterprise architecture

centralized

decentralized

shared resources

stable team

SCRUM

shared vision

innovation

matrix organization

center of excellence

pooled architecture resources

enterprise architects

high price solutions

hype

role of enterprise architecture

frameworks

programmer analysts

solution architects

data modelers

information architects

The Hedgehog and the Fox

Archilochus

Isaiah Berlin

Hedgehog Concept

philosophical differentiators

business focus

development capabilities

agile staffing

synergistic multipurpose personnel

operations architecture

advanced business users

self-service is an accelerator

stakeholders frequently palaver

real transparency not virtual

business first

participators not spectators

new philosophy of enterprise architecture

taxonomy and organization of enterprise architecture

enterprise architecture frameworks

TOGAF

Zachman

business architecture and governance

information systems architecture and governance

information architecture and governance

control systems architecture and governance

operations architecture and governance

cross-discipline capabilities

1.1 General Background

Regardless of the type of architecture, architecture itself is an organized accumulation of knowledge within a particular domain. While we generally conceive of its representation as a set of diagrams, containing specific notations and taxonomies of symbols and glossary terms, an architecture may actually be represented using anything that can be arranged in a pattern to record information.

The earliest forms of architecture relate to architecting buildings, monuments, military disciplines, organized religion, music, storytelling, and various other forms within the arts. These early forms of architecture of course predate computer-related architectures by thousands of years. That said, it is worth noting that there are a number of common elements among architectures irrespective of their relative age, such as forms of standardization, reusable structures, the accumulation of knowledge, and providing a context for understanding something.

Needless to say, anyone can be an architect in a topic in which they have a deep understanding and appreciation of. While one obvious difference among architects is the amount and variety of pertinent experience, the less obvious difference is the degree to which an architect recognizes the potential forms of standardization, reusable structures, accumulation of knowledge, relationships among the components, and use of architecture as an accelerator to more rapidly understand the context and scope of a particular topic or to rapidly convey it to another.

Architectures as a result must be easy to understand. This should not be misconstrued to mean that architectures must be simple. In fact, an architecture that communicates a vast amount of knowledge may be quite intricate and detailed so that it can successful at conveying a large accumulation of knowledge, the context of that knowledge, and key interrelationships among that knowledge. That said, the notation, taxonomy, symbology, and glossary should be easy to grasp so that the wealth of knowledge contained therein can be rapidly assimilated in layers that begin at a high level.

1.1.1 How Did We Get Here

If asked how many senses we have as a human, many of us would still say five, and we would be able to cite the five senses listed by Aristotle (e.g., sight, hearing, smell, taste, and touch). Later, if we were paying attention of course, we would learn that there are at least nine.

These would include:

■ thermoception—the sense of heat or absence of heat against the organ named skin,

■ equilibrioception—the sense of balance as determined by the inner ear,

■ nociception—the sense of pain from various locations in the body equipped with pain receptors, and

■ proprioception—the sense that tells us where our body parts are without being able to see or feel them with our hands.

Some neurologists also include the sense of hunger and thirst, and then some people can detect electric fields, while others can detect changes in barometric pressure in their sinuses detecting weather fronts, and so on.

The basic point, however, is that we get a sense of many more things as we experience life, and although we may share many of the same senses, what senses we are conscious of and what each of us learn will differ depending upon the particular journey we travel.

While still a teenager, in the 1970s, I was given a tour of the Loeb Rhoades & Company offices in downtown Manhattan, which was one of the last big brokerage firms that still operated without automation. Upon exiting the elevator I was escorted into a large smoke-filled room of desks by my girlfriend’s dad, who incidentally smokes cigars—they still allowed smoking indoors within offices at that time, arranged in rows and columns without any partitions, where people answered classic rotary telephones to accept telephone orders from customers. There was no e-mail or texting, no Facebook, and no Twitter.

Orders were handwritten on paper tickets that had sheets of carbon paper inserted between them so that there would be copies on individual pages, which were manually collected from desktop baskets by a clerk and taken to the next large room for collation and distribution where they were written into journals before being batched and bundled together for delivery to the floor of the exchange.

A decade later upon graduating from CUNY Brooklyn College and getting a job on Wall Street, I found users who, instead of writing on pads with carbon paper, typed on bulky green monitors that provided access into an early version of CICS applications on IBM mainframes. By this time, when business users explained the business, it was now expressed in terms of what information was being entered into fields on the display screen that scrolled up and down and across using arrow keys, followed by pressing the enter key. When you asked them what happened after they press the enter key, they simply tell you that they do the next one.

Other than the few old-timers that were nearing retirement, business users had little awareness of what happened after they entered data, other than the reports that they could run on a dot matrix printer. Recalling these things makes me feel old. However, I am encouraged by the fact that my doctor tells me that I am amazing healthy, and that I at least have a few good hours left in me.

What was important to me back at the time was the realization that I had witnessed a rare glimpse into history, where a decade earlier I had viewed the last business users that manually processed the business as a routine part of their day-to-day activities. If only I had known at that time, I would have hurriedly interviewed them, posed for group pictures, and chronicled their activities among the flow of paper and ledger entries.

Another decade later, the growth of midrange computers caused data to spread out of the master files of IBM mainframes into minicomputers of various brands, shapes, sizes, and colors, significantly expanding the computing landscape and its associated data footprint, data designs, and internal representations.

Shortly after that bulky personal computers began emerging under or on top of desks, but luckily their limited disk space capacity relegated them to mostly composing correspondence. This however was to turn into a story something like “The Trojan Horse” as disk capacity grew to house countless business files and databases redundantly and in many ways.

Complexity was on the rise with business users now originating data on mainframes and across a myriad of midrange computers to support their need for information. Similar to data, business rules were being buried in multiple applications across the midrange computer landscape. Soon business users quietly began developing their own shadow IT organizations using desktop tools such as Lotus Notes, MS Access, and Microsoft Excel to manage data that made them more productive.

Increasingly, the number of disparate computer platforms, databases, data files, data formats, data type codes, data aging, and data quality issues launched automation complexity through the roof. Thousands of software products, technologies, and tools poured into businesses and thousands of applications were developed, purchased, and modified.

Another decade passed and the “Y2K scare” did not cause the end of the world. Instead, laptops rapidly replaced bulky personal computers under and over the desk. The last of the business old-timers were gone and production data spread out across millions of Lotus Notes, MS Access, and Microsoft Excel applications on Windows servers and laptops. The shadow IT organization within the business had no source code control, no testing procedures, often no backups, and operated away from production equipment without disaster recovery protections. These were exciting times.

Another decade later, we arriv...

Table of contents

• Cover image
• Title page
• Table of Contents
• Copyright
• Dedication
• Foreword
• Inside the Cover
• Prologue
• The Main Characters
• Culture
• Part I: Introduction
• Part II: Business Architecture
• Part III: Information Systems
• Part IV: Information Architecture
• Part V: Control Systems
• Part VI: Operations Architecture
• Part VII: Cross-Discipline Capabilities
• Part VIII: Miscellaneous
• Appendix
• Index