Pragmatic Enterprise Architecture (2014) Strategies to Transform Information Systems in the Era of Big Data
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 arrive to the present. Laptops are being replaced by virtual thin client desktop architectures, and the use of smartphones and smart tablets have appeared everywhere and are being connected to the network. Smart eye-glass wear has emerged to become the highly mobile eyes and ears of the Internet traveling everywhere we go, hearing what we hear, seeing everything we see, and detecting everything that catches the movement of our eye, a far cry from the world of carbon paper in less than half a lifetime, with no sign of it slowing down anytime soon.
There is software around us in our daily lives, including in our:
- cars,
- cable boxes,
- telephones,
- watches, and
- CD-DVD players.
The number of automation products is amazing. To begin, there are over 50 database management systems, 40 accounting products, 30 Web browsers, and 35 word processing products.
There are thousands of software products for mainframes, midrange, personal computers, smartphones, and tablets across a variety of areas of automation, such as:
- data center operations
- production support
- job scheduling
- system administration
- utilities
- security
- networks
- operating systems
- workflow
- content management
- collaboration
- data management
- metadata management
- software development
- software testing
- software deployment
- business applications
- publishing
- reporting
- desktop tools
With all of this going on around us, one of the roles of an enterprise architect is to develop strategies that keep all of this from getting more complex than it has to be.
1.1.2 Understanding Business
While it may seem obvious that a good understanding of the business is essential for the success of enterprise architecture (EA), all too often EA retreats into a self-referential technical shell. In some cases, this leads to EA actively avoiding the business. Many problems flow from this attitude, including the inability for EA to properly influence the enterprise. After all, business people are unlikely to listen to an organizational unit they never interact with, and whose value they are unsure of. Even the concept of the divide between IT and the business is hurtful to EA's mission. If anyone thinks this divide truly corresponds to reality, then since EA is not part of the business, it must be part of IT. IT is generally poorly thought of by business people. It is seen as populated by individuals who are more oriented to the IT industry than the enterprise they work for, and who ultimately have less of a stake in the success of the enterprise than the business has. Clearly, EA will be diminished if the business thinks of it in the same way as it thinks of IT.
To properly gain an understanding about business, the best approach is for EA to first gain an understanding of business people. Generally speaking, a business-minded person has a clear focus, which involves weighing the numerous considerations to increase profitability, survivability, and market dominance (or to meet other business goals if the enterprise is a nonprofit). A business-minded person eagerly overcomes obstacles to achieve their goals. They are driven to learn what they need to know to succeed, who they need to succeed, and they view capital, manpower, and automation as tools for achieving each milestone on the path toward meeting their goals. Without business-minded people, the enterprise will fail.
If an organization places an obstacle in the path of a business-minded person, the business-minded person will either overcome the obstacle or leave for an environment that presents fewer such obstacles. A business-minded person sees their success as tied to the achievement of the goals they have set.
Unlike individuals in IT, there are usually readily identifiable metrics that can measure the productivity of individuals in business. In for-profit enterprises, the business-minded individual is primarily driven by the profit or loss on bottom line after accrued expenses, liabilities, capital outlays, and exposures to risk. It is also our experience that most business-minded individuals do not concern themselves with compliance and regulatory issues unless it they are to be held personally responsible in some real and meaningful way.
1.1.2.1 Direction of the Business
Strange as it may sound, IT may be engaged on initiatives and projects that may not support the direction that the business desires to go. This situation is all too common in large organizations, where few individuals understand what the business direction is for the enterprise as a whole, or for any individual line of business. Yet, it all begins with the business strategy as the most important element that an enterprise architect should grasp before making recommendations that may change direction or divert resources to any initiative.
The role of EA, first and foremost, is to develop various frameworks for automation that align business vision and strategy with IT delivery.
1.1.2.2 Pain Points
While supporting business direction is the highest priority, a close second is remediating business pain points. The important thing to recognize is that there are hundreds if not thousands of business pain points that will be present in any sizable company.
As such, finding pain points is not a difficult task; however, identifying the more important ones takes a good deal of effort, albeit effort that is critical to ensure that resources are not squandered on pain points less valuable to the business, leaving the ones that would be the most valuable for profitability undiscovered.
Business has no problem understanding the notion that all pain points cannot be remediated, and that all points will never be remediated. Like pet projects, individuals will always have their favorite pain points that they want remediated. Once pain points and pet projects are inventoried, along with their projected cost, schedule, personnel resources, ROI and business benefit, and associated business sponsor, then they may be evaluated and prioritized among competing pain points and pet projects for anyone to openly view. Giving the potential list the light of day is the best way to get the less beneficial projects withdrawn and quickly forgotten about.
Companies that shift to such approaches including complete transparency often experience significant decreases in the number of pain point projects, pet projects, change requests, and new automation requests, leaving more resources available for the activities that optimally enhance business profitability.
1.1.2.3 Business Problems Common to Large Organizations
A sailboat surges forward more rapidly, the better the wind fills its sails. In any race, a subtle adjustment of a rope and/or the rudder simply cannot be made by committee.
Whether it is to meet competitive pressures or simply a desire to control one’s own destiny, the motivation to make decisions as locally as possible will always be necessary. At the same time, in a place far away from the front lines of the business, centralized areas will yearn to control many of the same decisions to orchestrate an overall strategy.
That said, both sides are right, and both sides are wrong; however, once the appropriate principles have been identified, the answer is simple.
Big companies can grow through a variety of methods. Depending upon their available capital, they may expand their business internally by establishing additional branch offices, sales staff, third-party distribution channels, and products. Depending upon legal restrictions, a company may expand by leveraging the capital and energy of others by franchising, through arrangements such as a license, joint venture, partnership, dealership, and distributorship. The most common method of expansion used by the biggest companies is merger and acquisition, and rapidly emerging is expansion by distributing products and services using the marketplace of the future, the Internet.
The large public sector or other not-for-profit enterprises grow through expansion of the scope of their mission or mandate. Consolidation, including mergers of enterprises, can happen here too, and the emergence of the Internet is also a force for expansion.
The most egregious architectural challenges faced by large enterprises stem from business and IT expansion from mergers and acquisitions, and the complexities that ensue such as developing a massive patchwork of Internet applications that offer thousands of products and services globally. Some conglomerates resolve their architectural challenges by investing in the elimination of complexity that resulted from their most recent acquisition by rapidly consolidating their business and processing into either the previously existing or acquired set of business and IT operations (or combination thereof), hence retiring the acquired business and IT operations.
Some conglomerates cannot choose to combine their acquisitions into their existing operations or cannot combine their acquisitions into the existing operations because they do not have a comparable business and IT operation to consolidate them into.
The list of business problems most common to large companies is still much longer, and of these, there are a few that reoccur frequently such that they should be seriously considered as a means to significantly reduce operating cost and enhance business agility.
Some of the less obvious problems that remain hidden within the organization until expressly searched for include the emergence of shadow IT organizations, inconsistent processes and procedures, a lack of frameworks, and the lack or inability to identify and capture reliable metrics.
Some of the more obvious problems that reveal themselves over and over again include the challenges of integrating systems because of the fact that there is such a poor understanding of the data landscape within ones’ own automation systems, while poorly understood differences in functional capabilities between ones’ own and acquired automation systems provide another source of difficulty in integrating automation systems.
1.1.2.4 Shadow IT Organizations
One problem common to large organizations is the so-called Shadow IT Environment. It is a serious problem for the entire enterprise. Shadow IT environments are information processing environments that have been developed from within business departments without involvement or guidance from IT. These environments often utilize desktop tools, such as Microsoft Excel, Microsoft Access, E-mail, instant messaging, file formats, and anything else the business can use without getting IT involved.
The occasional use of technology by business is one thing, but once motivated to avoid IT to meet their needs, business staff can go further and faster than most any IT department. They can organize the technology they are working with to capture Production data and mold it to become increasingly competitive. In doing so, they begin to create a “Shadow IT Organization,” by hiring dedicated resources that deal with their automation needs directly—either to administer them or even to develop small solutions with them. This trend can be pushed even further until something resembling a full-blown IT organization existing within business departments, but are entirely independent of enterprise IT, their standards, and protection. Naturally, in this model, EA is also excluded by the business as EA would certainly have to report the situation to IT management.
Environments with enterprise IT and EA involvement incorporate many disciplines that Shadow IT lacks. A small list gives some idea of the scope of what is missing, such as standards that pertain to application architecture, information architecture, data in motion architecture (e.g., ETL, ESB), directory services architecture, job scheduling architecture, infrastructure architecture, source code control, data management, testing levels, management approvals, production backups, data security, production controls, system access controls, controlled backups, disaster recovery, business continuity planning, application portfolio management, and production support, to name some. Very rarely can one find these present in a Shadow IT Organization.
A Shadow IT Environment deliberately avoids the skills and disciplines provided by IT, as these add additional costs and delays. Often the business doesn’t understand why standards and procedures are necessary for something that they could simply create themselves. In fact, many IT resources don’t understand why standards and procedures are necessary either. For these characters in our play, their focus is on meeting ad hoc business needs in a few days or weeks, as opposed to months or years. At first this is easy, but eventually a Shadow IT Organization will find itself in difficult situation.
Problems include:
- As time passes, technology changes and the Shadow IT Environment personnel find that it uses tools in a way that prevents them from being upgraded. They have to retain old versions, or obsolete technologies just to keep the environment functioning.
- Tools and techniques are selected in isolation for each business need. As the Shadow IT Environment grows, so does the complexity of it, and so does the need for resources to administer it. Eventually, no further resources can be allocated for continued growth.
- Solutions in the Shadow IT Environments are heavily connected to particular contributors. The lack of maturity in the development of these solutions means that individual contributors are essentially part of these solutions. If the individual contributors leave, the solution becomes unmaintainable. Strangely, the individual contributors are often praised for their hard work and ingenuity, rather than recognized as creating risks, which can vary. On the low end, a developer may simply act as lone developer that inadvertently makes the business dependent upon the individual developer. On the high end, a developer may plan to coerce the enterprise by placing “time bombs” in an application, whereby a computer program that has been written so that it will stop functioning after a predetermined date has been reached. If the developer no longer works at the enterprise when this happens, he or she will likely be recalled by the enterprise to fix the problem. Does this really happen? Yes, and unfortunately we can write an entire book on just this topic.
1.1.2.5 The Benefits, Costs, and Risks of Shadow IT
Shadow IT organizations emerge when the enterprise IT organization fails to support business at the pace required by the business. Initially, Shadow IT organizations meet pent-up demand within the business and appear to save the business significant time and money (e.g., to get much needed reports to facilitate business decision making). Although this may be the situation initially, a Shadow IT organization can rapidly grow to represent a significant waste of budget and resources.
The notion that Shadow IT organizations save money stems from the fact that the business can achieve somewhat instant gratification by creating their own mini IT departments. In contrast, the costs of Shadow IT organizations are high, but typically only appear later in time. These costs often come from the creation of a staggering degree of redundancy of reports, applications, and duplication of development personnel who are redundant with the IT organization as well as redundant across all other Shadow IT organizations across the business. Shadow IT also creates a staggering amount of data duplication, as well as a myriad of data quality issues. To be fair, IT application development teams are not blameless in this respect either.
Closely related to data duplication is another significant risk—the origination of data outside any true, IT-administered production environment. Sometimes these data many never find its way into a true production environment and hence are never available to any of the other appropriate stakeholders across the company. In other cases, it does get into production environments, but no one can easily identify where it originated from and when.
Many additional risks exist in Shadow IT and stem from the lack of IT standards and architectures. Some of these risks have immediate cost impact, while others many not be manifested in terms of unnecessary cost for years. Such risks include the application complexity, data landscape complexity, not testing, not having source code control, not being compliant with regulatory agencies or legislation, not having the ability to properly restore an application or database from a backup, and not submitting a job on time because it was run manually and not under the control of a job scheduler.
There are ways to prevent Shadow IT organizations from emerging and growing, but the best way is to provide a clear incentive to the business to get their needs met in a manner that is better, cheaper, and easier than creating a Shadow IT organization. We will discuss this further in the section that addresses the new philosophy of enterprise architecture.
In the end, what the enterprise must do is to get control of the IT organization to make it responsive to the needs of the business. This is a key role for the modern EA practice, as is the next challenge of inconsistent processes, which occur in business departments as well as IT.
1.1.2.6 Nonstandard Processes
Another business problem common to large organizations is that of nonstandard or inconsistent processes, which can occur in any department across the company, including among supporting vendors and service providers, and representatives of your company. This includes external distribution channels, outsourced service providers, remote call centers, external data center hosting providers, and personnel working from home offices.
Nonstandard processes are manual processes or procedures that can vary individual by individual as they perform what should be the same task. Whether the customer is an internal customer or an external paying customer, the level of service that each individual delivers should not vary randomly. Essentially, every customer should expect to consistently receive the same great service every time and they should expect to receive the same great service as every other customer regardless of who provides that service. If companies or departments decide to provide a premium service to its premier customers, then the same rule holds; customers receiving premium service should receive great and consistent premium service regardless of who provides that service, and customers receiving the nonpremium service should receive great and consistent nonpremium service regardless of who provides that service
To best understand the value of a consistent process, let’s imagine how businesses that have tight profit margins, such as printing businesses and fast food chains, regiment and tune their manual processes to be as efficient as possible.
When a competitive business with tight profit margins standardizes their manual processes, they must carefully determine the most cost-effective process possible to perform each service they provide including each of the tasks that are necessary to invoke to deliver that service. They must then train their staff to perform the process with exacting detail. If one of these businesses fails to operate as a well-oiled machine, its profitability, and possibility its viability, will assuredly decline.
Every department within a big company renders a particular set of business capabilities that complement the enterprise in some important way, which are performed as activities by the individuals within that department either manually or with the aid of automation. To be more precise, each type of business request, such as “a request to generate a particular pamphlet,” may have to leverage one or more business capabilities.
In a nonstandardized environment, the most experienced members of the department will use an approach that is superior to junior members of the department. This superiority may manifest itself in a number of different forms, such as producing outcomes that may be less error prone, less time consuming, less effort, or provide a better customer experience. Depending upon the company and department, it may be important for management to determine their objectives and then design the most appropriate process that should be adopted to deliver each type of request, and then ensure that their staff members receive the training or tooling to ensure that the desired process is consistently performed.
With few exceptions, nearly all departments within nearly every enterprise operate using nonstandard processes. This creates a number of business problems, the first being that objective measures are generally not present under these circumstances, and as a result, there is usually no clear path to achieve verifiable process improvement to control, never mind outcomes that are simply consistent and predictable.
1.1.2.7 Lack of Useful Frameworks
Similar to nonstandard processes, inconsistency among applications reduces chances of software component reuse and increases complexity causing individuals more effort to understand how something works ultimately leading to longer and more costly maintenance. The cause of inconsistent IT components is the lack of useful frameworks that would cause software developers and infrastructure support staff to use a common approach within each architectural discipline.
Interestingly, this is one of the least recognized business problems, costing manpower to be wasted and misdirected over prolonged periods of time. The reason it is the least recognized is that unlike a business problem that is tangible in the sense that everyone can see, this manpower expense manifests itself by something that is absent. That said, what is it exactly and why is it so important?
If we go back to the early days of automation, there were no IT departments. Early automation often consisted of a big machine the size of a small automobile placed in the middle of the mail room. These machines sorted 80 column cards in accordance to the pattern of large, color-coded cables plugged into a square board that had a grid of holes that the plugs fit into that slid upright in and out of one end of the machine.
The concept of programming at this time was the ability to customize the sort columns and sort order by rearranging which holes the cables were plugged into, which was determined depending upon what the particular business needs were, such as sorting by zip code to find contributors within a particular district to raise campaign funds. This was communicated by a business manager telling someone in the mail room who was trained to rearrange the cables to make it sort differently.
Not until the emergence of the first mainframes, where there were cooling requirements, was there, typically a room dedicated to automation called the “computer room,” with specialized personnel to support the computer room, such as a systems manager, systems programmer, a few computer operators, application programmers, and a roomful of card punch operators.
As computers became more advanced, the process of programming the machine by arranging wires that plugged into a board was replaced by software. The machines still used punch cards, but now the business capabilities being automated were the core business capabilities in accounting, consisting of a single customer master, product master, and transaction master, which generated the journal entries that were accumulated to populate the general ledger.
Instead of one big machine sitting in the middle of the mail room, now the entire automation landscape consisted of a single separate computer room with large air conditioners, a mainframe computer with a card reader and a main console. Cabinets that housed the punch cards of each master file were typically just outside the computer room, where a handful of application development and systems staff had their desks where they could look through big windows into the computer room. The budgets associated with IT were now a few million dollars for a major department.
Fast forward a few decades later and we find that the typical automation landscape of a large organization consists of multiple data centers spread across the globe, tens of thousands of computers that range in size from mainframes and super computers to personal computers, smart phones and tablets, hundreds of thousands of files, thousands of databases, millions of lines of application code spread across repositories around the world, thousands of IT staff, and a budget in the billions.
As existing applications evolve and new ones developed, they employ several dozens of different types of technologies. There are various types of networks, operating systems, job schedulers, security systems, database management systems, change management tools, hardware platforms, reporting tools, and so on, in use across the same enterprise, requiring people who have been trained in each flavor of each type of technology, all doing things differently. While executives can see a lot of people in IT, they do not see the lack of useful frameworks for each type of technology. While some executives may detect one or two areas where commonality would help, they generally lack familiarity across the many types of technologies to see the true impact of many people using many technologies across many types of technologies in different ways.
The sheer volume of existing automation components across large enterprises today contributes to a level of complexity that no one individual, or few individuals, can comprehend, and as if the challenge wasn’t big enough, there is no shortage of new types of technologies emerging all of the time.
To provide an example within the limited technology space of Big Data open source software, there are new workload optimization technologies, such as ZooKeeper, Oozie, Jaql, HCatalog (aka HCat), Lucene, Pig, and Hive, new integration technologies, such as Flume and Sqoop, new file systems, such as HDFS and GPFS, and new analytic engines, such as R language (aka R). Additionally, there are the countless non-open source technologies in the Big Data space.
The way to manage these technologies and organize the data that they contain in an approach that does not result in an upsurge of complexity where each individual reinvents their own wheel is to have useful standards and frameworks.
However, standards and frameworks themselves must be carefully envisioned and developed to address the challenges of the business. If standards and frameworks are out of date or poorly formed, such as being overly abstract, largely undefined, ambiguous, or inconsistently depicted, then one will have incurred costs for having standards and frameworks without the benefits.
In addition, it is often important for architectural frameworks to integrate with one another, such as involving data governance and information architecture. As one might expect to find, architectural frameworks of a large enterprise are rarely coordinated with one another as they are often developed under different organizations, which also means that these frameworks are not usually integrated with one another.
Like the various disciplines within IT, what would happen if each discipline of the military were to draw up plans independently? The most likely result would be a general unavailability of equipment, fuel, food, munitions, manpower, and surveillance support when needed, as well as the unintended consequence of potentially falling under friendly fire.
1.1.2.8 Lack of Metrics
When I was young my first car was a 1968 Buick Special. I used to tune the engine with just a timing light, although after a while I could do it by simply listening carefully to how the engine sounded. Either way, whether I used the timing light or judged by the sound of the engine, I was using a form of metrics. If I adjust the timing screw in the wrong direction, I could see the strobe light move further from the mark and I could hear the engine running less smoothly. If I did not have either a timing light or the sound of the engine to go by, we could be fairly certain that my car’s engine would be worse off than if I had just left it alone.
Similarly, a challenge to management is to have the need to improve business operations without useful metrics on hand to show how well things were running before adjustments are made and then useful metrics to show how well they are running after adjustments have been made. The simple timing light is no longer sufficient to tune the organization. Tuning a modern automobile needs computer-driven diagnostic tools that are information driven, and tuning modern organizations need computer-driven diagnostic tools that are information driven.
Metrics, however, cannot be a measure of just anything. Unless specifically measuring the opinions of your customers, such as their degree of satisfaction or sentiments, metrics should not be reliant upon the opinions of others. For example, to measure customer satisfaction or sentiment objectively one should be measuring the revenue per customer visit, customer referrals, and customer loyalty. In short, metrics must be measuring the right things in the right ways. Hence, the first trait that metrics should have is that they should be “strategic,” which encompasses being correlated and relevant to intended outcomes, and it must be reliable, as in originating from a reliable or trustworthy source, which cannot be circumvented by individuals looking for loopholes.
Another essential trait of useful metrics is that they should be easy understand by everyone involved across all areas levels of the organization so that individuals can get on board with them and then consciously or unconsciously move toward achieving the strategic objectives associated with the metric. Hence, another required trait of useful metrics is “simplicity.”
An additional trait that is important is that the metric must be available in a short enough time frame to still be useful. Having metrics originate from the end of an assembly line or from year-end earnings reports is sometimes too late to be useful. Hence, the next trait of useful metrics is that it must be “timely.”
The uses for metrics go beyond tuning a business or IT operation. When considering the largest enterprises that are reliably successful at incorporating acquisitions into their business and IT operations, the most important success factor is their ability to collect reliable and meaningful metrics on almost everything they do.
Customer experience metrics provide an ability to improve retention and growth, particularly for strategic customers within emerging markets. Business and IT operational metrics can provide operational radar into the efficiency of business capabilities within each department of the company, whether the department is a business department or IT department, and whether the business or IT capability is off shore or outsourced.
Metrics that are gathered through automation have advantages over metrics gathered manually, as automated metrics collection provide the only consistent and reliable source of objective information about what is happening inside your business. In the absence of operational metrics, it is difficult at best to reliably determine which staff members achieve the best results, whether it regards their productivity, the fact that they generate fewer defects or assist others more frequently, or create a greater level of customer retention. Without metrics, it is generally not possible to reliably determine whether changes to organizational structure, personnel, roles, or operational procedures are having an overall beneficial or detrimental impact.
1.1.2.9 The Pain of not Understanding Ones’ Data
First, there are a number of causes for not understanding ones’ data. Although it can be as simple as not understanding the business area associated with the data, the causes typically go far beyond a lack of business knowledge. However, even if one knows the business thoroughly, the sheer number of potential data points and their particular taxonomy tends to form an immense barrier to being able to comprehend ones’ data.
One essential step toward addressing this challenge is having the benefit of leveraging a business data glossary. A business glossary acts as a sort of business dictionary that has the business name of the data point with the synonyms that are used across the industry and other departments. It should also include a definition of the data point including how it is used, as well as some other business information, such as whether it feeds into the general ledger and whether the data point is governed by privacy rules based upon legislation and regulation, or simply as the result of promises that were made to the customer or other parties. Even though a good business data glossary is an essential foundational step toward understanding ones’ data, there are a myriad of other causes that still create a formidable barrier to comprehension.
Common barriers that are formidable are surprisingly numerous. One of the most difficult to address is complex database designs. Complex database designs are particularly common among purchased software products, where the ability to interpret the data requires the complex logic that was built into the application software. However, the data from complex databases and applications that are developed within ones’ enterprise can be just as difficult to interpret.
That said there are additional barriers that are also formidable. If we first assume that we have an excellent business data glossary, and a solid understanding of the database designs as to which physical database fields correspond to which business data glossary items, the next barrier is called “data quality.”
When dealing with data quality we may find that the formats of our data may be inconsistent, such as dates not all being in a consistent format of a four-digit year, followed by a two-digit month, followed by a two-digit day, but besides that we may find that the actual values of the dates make no sense, such as birth dates in the future, and death dates that precede the invention of electricity, or simply missing data values where the fields are simply empty.
There are additional causes for not understanding ones’ data, but these few give the reader an idea as to how easy it is to have a severe problem comprehending ones’ data, so that now we are ready to understand the pain this causes an enterprise.
The impact that is first and foremost for not understanding ones’ data is the high cost in time, money, and manpower associated with developing reports, data analytics, data mining, data integration, data virtualization, developing and maintaining applications, and the inability to establish business self-service for ad hoc reporting. In terms of business value to executives, this means that informed decision making is generally not possible unless there is a great deal of lead time available.
When put into perspective as a percent of IT budget, the statistics to look for are the ratio between the total IT budget to the budget used to generate reports and analytics, and the IT work months required to support a typical ad hoc report request. Optimally, the number of IT work months should be zero because the business user was able to find the existing ad hoc report in a few minutes or because they could create the ad hoc report themselves in less than an hour.
1.1.2.10 The Pains of not Understanding Ones’ Business Capabilities
To those among most industries, the notion of not understanding ones’ business capabilities is going to sound rather strange. In a mortgage bank, for example, the business capabilities involved in creating a mortgage are relatively well understood, at least by the individuals who work in those departments. The challenge is that the individuals outside those departments, unless they previously worked in those departments, generally have little understanding of the business capabilities that are supported within those other departments, particularly if we are talking about individuals within an IT department understanding the business capabilities of a business department, or vice versa.
In addition, as we had mentioned earlier, another major challenge is that even individuals within a given department often do not know much, if anything, about what happens within the automation systems that they use, even though they may use them on a regular basis. When developed in-house, knowledge of these automation systems resides with the IT team that maintains the application. When the automation system is acquired externally, then knowledge of its business capabilities resides within the vendor.
The impact of not understanding ones’ business capabilities is multifaceted. Perhaps most significant is that business capabilities that are not well understood can become regularly encrusted with new additional layers of business capabilities that attempt to deliver new or augmented business capabilities. One major bank encountered had so many layers of business capabilities added on to one of their business operations that in the end no one could definitively understand the accounting. As a result, interpretation of the accounting was performed by a team of individuals who poured over the figures and then prepared a summary of their beliefs to the CEO.
Another impact of not understanding ones’ business capabilities is the difficulties that arise when attempting to set up disaster recovery capabilities. Companies frequently find that they have to engage specialists to go in and inventory what business capabilities each department performs, what automation systems they use to support these business capabilities, and what databases and infrastructure are required to support these automation systems.
The merger and acquisition process is also impacted by not understanding ones’ business capabilities. If your own business capabilities are not well understood, then there is a much greater likelihood that acquired business processes and automation systems will have to sit side by side with your already existing business processes and automation systems, adding to the complexity, and of course the myriad of costs, associated with conducting business.
That said, perhaps one of the most important pain points of not understanding ones’ business capabilities is the inability to align organizations to strategic intent, and to accelerate and improve the quality of results.
As such, these represent a respectable sampling of some of the more common business challenges that are faced by many large enterprises, and how we generally got there. Now let’s understand IT.
1.1.3 Understanding IT
The first thing to understand about IT is that it is an outgrowth of business, which traveled through the premechanical age culminating with number systems and written language, then through the mechanical age which developed manually operated machines to perform mathematical calculation, then through the electromechanical age that harnessed electricity to represent and transmit information as analog electrical signals, and then to our present digital electronic age where information is encoded digitally as bits to be stored and transmitted over networks.
Just as business used automation to optimize the profitability of manual tasks for the production of goods, business used information technologies (IT) to optimize the profitability of mental activities for the processing, storage, retrieval, and analysis of information.
It is true that automation can be used for scientific research (e.g., supercomputers) or entertainment (e.g., computer game platforms), but for the vast majority of enterprises in which enterprise architects work, the primary goal is still to increase the top line (generate more revenue) or increase the bottom line (be more profitable).
From the next highest level perspective, the way to understand IT is to understand the high-level architectural disciplines that exist within IT, even if these are not always formally recognized. While it is not important for an enterprise architect to be an expert in all architectural disciplines, it is critical to know what the disciplines are, how they are defined, their scope, and the handful of fundamental principles that illustrate their proper management.
After understanding the various architecture disciplines, the next highest level perspective way to understand IT is to understand the mindset of engineers, which varies depending upon the degree of separation that they typically have from business.
However, there is another perspective that needs to be understood in order to fully appreciate the functioning of IT, and this is the difference between control systems and information systems. Different disciplines pertain to each of these families of automation system. Enterprise architects need to understand the differences between the two families and which architectural disciplines apply to each.
1.1.3.1 Varieties of Automation Systems
“Control systems” operate in the tangible world of physical objects. They may be measuring instruments, e.g., thermometers, anemometers, and steam engine governors. They may operate mechanical equipment, such as a soda machine that accepts money, determines denomination, authenticates currency, facilitates a product selection, routes product for delivery, and makes change. A “control system” may also be as complicated as a B-2 bomber, which is far too complicated for any human pilot to control without a computer.
In contrast to control systems, “information systems” strictly process information, such as the activities involved in the disciplines of bookkeeping and accounting, which crosses into the world of intangible ideas and concepts (e.g., journals, accounts, fees, and taxes).
One additional area of software system includes software for certain types of games that in some sense obey the laws of physics and operate within a virtual world of physical objects. These are an advanced type of “control system” which I call “virtual world control systems.” A “virtual world control system” is a hybrid comprising a “virtual world system” and “virtual control system.” The “virtual world system” replaces the tangible world and the “virtual control system” operates within the “virtual world system” allowing one or more participants (i.e., human or automated) to interact within the “virtual world system” through some sort of user interface.
There are some candidates for other families of automation systems. Artificial Intelligence (AI) is one. Yet, AI is more of one or the other, rather than a different family. AI applications can sometimes be classified as a control system because they operate machinery. Sometimes, they can be classified as information systems because they perform functions that are analogous to thought, such as making a decision on whether to extend credit. Perhaps the most accurate way to view AI is that there are components that are control systems, such as the body of an artificially intelligent device, and other components that are information systems, such as the brain of the artificially intelligent system.
It could also be argued that simulations and games are yet another family of automation system. However, they are comprised of a combination of control and information systems. Games are a variant of control systems in that they operate within and among objects of an imaginary world. Yet they are also a variant of information systems in that they track intangible ideas and concepts.
Although control and information systems can use many of the same tools, languages, and techniques, there are differences between them. Such differences include analysis, design, implementation, testing, deployment, and support principles. To illustrate just a few of the differences in their paradigms, we will discuss error handling, data handling, testing, and, most importantly, financials.
1.1.3.1.1 Differences in Error Handling
Although there are many differences, perhaps one of the most interesting differences in the programming of control systems versus information systems is the way in which they perform error handling.
Imagine the flight software of a B2 stealth bomber encountering a program error, say a zero divide, during a mission. The last thing the pilot would want is for the software that is flying the aircraft to suspend its activities so that it could take a program dump—which is what an information system would do to allow the programmers to find the error.
When a control system encounters an error, the software goes to great lengths to rapidly work around the problem so that flight may continue. In contrast, when an information system encounters an error, it automatically terminates its activities and produces a diagnostic dump to better facilitate discovery of the root cause of the error. With an information system, the primary concern is to protect data integrity and the quality of the information, and stopping its processing is a minor price to pay to protect information, particularly when it involves financial data.
Error handling is an illustration that control system analysis and design are dominated by a process-oriented focus, with an emphasis on control modeling to properly operate a piece of machinery.
1.1.3.1.2 Differences in Data and Testing
Information systems typically deal with a large breadth of information, while control systems deal with a comparatively narrow breadth of information. As a result, information systems have a variety of features emphasizing the criticality of data integrity that control systems almost never have, such as database backups and restores, forward recovery from backup, transaction rollback, distributed computing, and distributed data.
In contrast, control systems are typically physically centralized as opposed to distributed, they are more response time critical, and they are more likely to employ a variety of sensory I/O devices with few data points being received often at a high frequency (e.g., anemometer).
When implementing an information system, one of the decisions typically involves the selection of a commercially available operating system. In contrast, when implementing a control system, the task is often how to design the custom operating system and develop the custom I/O drivers.
As a result of having such a customized environment, the control system has a unique set of test issues. Unlike establishing the various testing levels for an information system, such as unit test, integration test, user acceptance, production, and disaster recovery, the control system has a variety of program-specific integration and test environments, such as host-based test beds, real-time closed loop test beds, real-time open loop test beds, operational test beds, and production units.
Regarding control systems, host-based tests depend upon a host platform that facilitate testing of the control system application; real-time closed loop test beds are test environments that provide feedback into the control system application; real-time pen loop test beds are test environments that do not provide any feedback to the control system application; operational test beds test the control system in operation; and production involves deployment of the operational control system.
While generating test data is not a trivial task with information systems, control systems, or virtual world control systems, the types of data that are involved and the support of differing types of test beds require a wholly distinct set of disciplines.
1.1.3.1.3 Financial Differences
The primary costs associated with an information system involve the development life cycle, deployment, ongoing production support, and subsequent maintenance.
Due to the enhanced custom nature of control systems, the primary costs also involve a significant manufacturing component, including product-specific hardware, operating system SDLC, firmware development life cycle, test bed development, various types of system tests, operational testing, assembly line development, manufacturing of production units, deployment of production units, and maintenance of production units.
Similarly, the profit areas for information systems are typically sales and licensing copies of software, as well as the associated maintenance of the software.
In comparison, the primary control system profit area is in hardware unit production and sometimes in maintenance and support agreements.
1.1.3.1.4 Varieties of Automated Systems Conclusion
Probably, the vast majority of enterprise architects will deal exclusively with information systems and may never see a control system in their professional careers. Yet, in order to fully understand the nature of IT, it is necessary to appreciate the variations in automation systems that exist.
The contrast between control systems and information systems will at a minimum allow an enterprise architect to articulate why a discipline that is popularized in the world of control systems may not necessarily apply to the world of information systems. There are many such misconceptions among the general public, who tend to associate computerized systems with the military and space exploration, rather than with the financial services industry or pharmaceutical sector. Unfortunately, this may also extend to senior executives in large enterprises who may have difficulty understanding the role of EA—or may misconceive it completely. Realizing the differences between control systems and information systems can help EA properly articulate its role in the enterprise.
1.1.3.2 Automation as a Cost Center
Understanding the mindsets of others is the first important step toward relating to them. There are mindsets rooted in gender, generation, ethnicity, language, local culture, nationality, politics, religiosity, sexual orientation, sociability, athleticism, education, professional vocation, and income levels. These mindsets form the value systems, motivations, and the fabric of social interactions.
The primary focus of business users is directly tied to the mission of the enterprise, commonly which is realized by applying capital to produce sales of products and services at a profit, it could be to protect the citizens of a nation from those who might threaten harm, or it could be achieving a humanitarian mission in some particular part of the world.
From the perspective of business users, however, IT is often viewed as just a cost center that has lots of technically minded people that are stereotypically hard to talk to. It is thought that business users are not able to understand them, and of course, vice versa. The way business frequently sees it, IT continues to move further away from thinking like the business the deeper into IT areas of specialties that one goes.
It is true that some IT disciplines are complex, just as are many other disciplines, such as medical, pharmaceutical, and military intelligence. What business must understand is that competence in these areas of specialization is not measured in terms of the mission of the enterprise, but instead is in terms of the number and type of educational degrees and licenses earned over their lifetime.
From the perspective of business, its customers are viewed as those whom the enterprise provides goods and services to. From the perspective of IT, its customers are viewed as the business users, or if business users are not visible to them, its customers are the IT management that they do have visibility and awareness of.
In a healthy organization, the role of enterprise architecture is to understand the perspective of business and IT, as well as their respective needs and pain points so that business can understand and participate in prioritizing the use of capital and IT resources.
1.1.3.3 Our Need to Reduce Degrees of Separation
One important factor to help one understand IT is to establish an appreciation for the mindset of engineers. Many are familiar with the stereotype of IT engineer, such as being better in mathematics, science, logic, and puzzles than in dance, music, sports, public speaking, written communication, and people skills.
While generalizations can prove extremely misleading when evaluating any individual from a population, it is fair to observe that for the most part, engineers are natural problem solvers who strive to learn the inner workings of things so that they can better maintain them.
While any given area of technology is not overly difficult to understand, many areas are associated with a large amount of information, such that individuals who specialize cannot specialize in large numbers of them, as it simply becomes impossible to keep up with the volume of change regarding the related products and technologies. This volume of information together with the predilection of engineers being technology focused leads to typically being out of touch with the things that other individuals must focus on.
We must remember that IT was not always this way. In its early days, all IT resources sat with the business user. The number of specialty disciplines in IT back then was few. One of the points of this book is to get a sense of how many disciplines in IT there typically are in a large enterprise.
As a result of the number and depth of these disciplines, the degrees of separation from business will become apparent. One of our goals as enterprise architects is to demonstrate ways to reduce those degrees of separation in an efficient and effective manner.
1.1.3.4 Enterprise Architecture: Centralized vs. Decentralized
A theme that we encounter from time to time in large organizations is whether enterprise architecture should be decentralized and its resources distributed out to lines of business. When global organizations consider the advantages and disadvantages of centralizing their architecture capabilities, the arguments that are raised against centralization do not vary much from company to company. As a means to present this classic debate in one of its most native forms, we shall create a hypothetical situation with a number of actors, two of whom engage in the arena of an e-mail encounter.
A global conglomerate, which is based in the EU, Finansiella LTD, this week announced the consolidation of all country-level Chief Information Officer (CIO) and Chief Enterprise Architect (CEA) positions into a global CIO and CEA position, respectively. All former CIO and CEA positions will be renamed to Relationship Directors and Solution Architect Directors, respectively, with all architects moving into the organization of the CEA, which itself is now within the organization of the CIO.
Vladimir, formerly a country CIO, is now a Relationship Director, a title that he does not find appealing. As one would expect, he is a “Type A” personality, a temperament marked by excessive competitiveness and ambition, an obsession with accomplishing tasks quickly, and a strong desire to control as much as possible around him. Rather displeased with the announcement of the organizational change, Vladimir fires off a lengthy e-mail to Jean-Claude the new global CIO, and copies Antoinette the new global CEA, as well as all former CIOs and CEAs.
With the press of a button, the e-mail arena, complete with players and spectators, has now been formed. This e-mail exchange will explain and illustrate many of the arguments of centralization and decentralization for enterprise architecture.
To: Jean-Claude@finansiella.com
From: Vladimir@finansiella.com
CC: Antoinette, CIO MGT TEAM
Subject: architecture consolidation/concerns
First I should note that I may be more sensitive to this topic more than some as I come from a country where centralized planning replaced the ability of individuals to perform at their best, stifling innovation, and resulting in an inefficient and unresponsive bureaucracy. As such, the consolidation of architecture resources requires careful consideration, as it poses considerable risk to budgets, schedules, software quality, integration, deployment, and maintainability of our business automation.
More specifically, my initiatives are too large and complex, with aggressive schedules to suggest that we shift operating models in mid-stream. I apologize in advance for the length of detail that I supply below, but at its conclusion, I offer some suggestions that I would like to offer as possible alternatives for your consideration.
To begin, I concur that consolidation of architecture can be beneficial for a number of situations.
1. A consolidated architecture group best facilitates knowledge sharing across initiatives.
2. An inventory of architectural skills can be better managed from a consolidated architecture group.
3. Awareness of cross architectural disciplines can also be better facilitated from a consolidated architecture group.
4. Synergies between architectural disciplines can be better detected and pursued.
5. When initiatives are small or medium in size and scope, it is extremely effective at rendering critical architectural resources in and out as needed, as the costs of maintaining a standing team of the various specialists required are certainly prohibitive for a small or medium initiative. The resources come in, resolve the specific issues, and then move onto the next assignment.
6. There are times that architecture support simply requires answering a simple question, pointing the developer in a particular direction, or supplying the appropriate document or example, not requiring in-depth familiarity with the initiative, acting as an architectural help desk. This would also be true in the situation where the architectural direction is routine and repetitive across a large number of initiatives around the globe.
That said, it is not apparent that a consolidated approach works best for large, complex, long running initiatives, such as the initiatives currently underway in this area of the organization aligned with my area of expertise for the following reasons:
1. On large initiatives, it is significantly more critical that the architects become intimately familiar with the system and the business problem, which is simply not possible when using shared resources. The costs are naturally higher because the resources being deployed must spend time getting familiar with the initiative before they can be reliably effective, not to mention the additional time needed that is needed to get familiar with the various challenges facing the initiative.
This assumes that the appropriate resources are even available when needed. It also assumes that these resources have outstanding soft skills to quickly blend into the personnel of my team.
2. To maintain a stable team of personnel, I ensure that the members of the team develop a bond that motivates them to remain working with the team more like a family. They conduct SCRUMs, work together, lunch together, and socialize outside of the workplace. As a result, we have an atmosphere where they are more inclined to help one another by putting in the extra effort to not let the rest of the team down in achieving the milestones of the initiative.
3. When the same individuals dedicate large amounts of their time and effort on developing something, they develop a sense of pride and ownership. The team in Apple that developed the iPhone did it because they were emotionally bound to their team and their mission, as well as the opportunity to be successful for such a historic visionary as the legendary Steve Jobs.
4. It becomes possible to establish a shared vision among a team when the members of the team are not rolled in and out as needed.
5. Familiarity with an initiative can help foster innovation instead of hampering the creativity of individuals by allowing them the opportunity to amass the level of knowledge necessary for innovations to occur.
6. A consolidated architecture team requires a complex matrix organization with architects reporting to the central architecture organization as well as to the management of each initiative they support.
7. Having multiple masters creates confusion and reduces an individual’s focus on the priorities of each manager.
8. Practice groups or centers of excellence provide a better alternative to a consolidated architecture group.
9. Attaining consensus on a team with staff rotating in and out is more time consuming, which would be highly detrimental to an initiative with an aggressive schedule to meet business needs.
10. Splitting responsibility and authority between a centralized architecture group and initiative management causes the initiative manager to have responsibility for schedules and budgets without authority to drive the team to achieve the objectives of the initiative. Likewise, centralized architecture has authority over architects, but lacks control over schedules and budgets.
11. Priorities may cause pooled architecture resources to be applied elsewhere in the organization, impacting my initiative.
12. If it were truly intended to give enterprise architecture real authority, then we should probably consider giving enterprise architecture direct responsibilities for enterprise projects upon which it could apply its own standards.
In summary, I would like to suggest that the few initiatives that are large, complex, aggressive in schedule, and business critical, particularly the ones that are in mid-stream, be permitted to continue without disruption to secure the greatest probability of success.
Best regards,
Vladimir, Relationship Director
As soon as this e-mail is received by former CIO and CEA staff members, the organization is abuzz with backchannel discussions speculating on the possible reaction by the new global CIO, Jean-Claude.
After Jean-Claude reads Vladimir’s e-mail, he phones Antoinette, his new global CEA on her mobile phone and tells her to develop an appropriate response for Vladimir copying the same audience.
Antoinette reviews each of the points that Vladimir presented in his communication to the management team, collects her thoughts, notes to herself that this is an opportunity to demonstrate her abilities in her new position, and develops her first e-mail to the newly reorganized management team at the request of her new manager. Just before sending the e-mail, Antoinette sees the opportunity for a constructive mentoring opportunity and gives Vladimir the courtesy of conferring with him to discuss her pending reply before she sends it, thereby allowing him to experience how he might have better handled the matter.
To: Vladimir@finansiella.com
From: Antoinette@finansiella.com
CC: CIO MGT TEAM, Jean-Claude@finansiella.com
Subject: Fw: architecture consolidation/concerns
As we discussed, I appreciate your efforts in placing considerable thought with regard to this important issue. It is only through a rigorous intellectual process that we can arrive at the best model for moving forward to facilitate our competitive position. Please find my comments addressing your concerns in italics, and at your convenience I will be happy to discuss them in greater detail.
First, please know that complex projects such as yours will have dedicated resources as well as resources that are required on demand as appropriate to meet the priorities of the business, with a dotted line for reporting into you and/or your project management personnel.
1. On large initiatives, it is significantly more critical that the architects become intimately familiar with the system and the business problem, which is simply not possible when using shared resources. The costs are naturally higher because the resources being deployed must spend time getting familiar with the initiative before they can be reliably effective, not to mention the additional time needed that is needed to get familiar with the various challenges facing the initiative.
This assumes that the appropriate resources are even available when needed. It also assumes that these resources have outstanding soft skills to quickly blend into the personnel of the team.
The ramp-up of time of resources is a valid concern that I share, and is one that I intend to help you better resolve.
If we look at the big picture for a moment before addressing the specific points you raise, one of the first challenges we face within any initiative is the time consuming and labor intensive process of identifying and interviewing candidates, determining which candidates possess the appropriate level of expertise within the architectural disciplines that are needed, onboarding them, training them in our standards and processes, not to mention then acquainting them with of our business automation systems and operational support systems. Our consolidated model forarchitecture removes this overhead from your concern and streamlines the process of assigning a qualified resource when they are needed.
To address the valid concerns you raise, the biggest weakness of the model that embeds architects within specific initiatives is that for non-complex projects embedded architects have idle time with no easy way to utilize their expertise for other activities. This often leads initiative managers to assign them other work that could otherwise be performed by a less expensive resource. For large complex projects, embedded architects become a single point of failure.
Consider the following; in the situation where the ramp-up time is low, consolidation is certainly the best option as it allows architects to adapt to priorities as needed, thereby avoiding embedded architects and the issue of idle time. However, in the situation where the initiative is large and complex, the consolidated architecture model still allows for dedicated architects who work with the team, but with the additional advantage of being able to draw upon the resources of peers and train secondary and tertiary backups.
This approach increases overall flexibility for an initiative when either the workload increases or decreases, while eliminating single points of failure. As a result of cross training, I believe that we will find that the ramp-up time actually decreases each time you require the expertise of any particular architectural discipline.
2. To maintain a stable team of personnel, I ensure that the members of the team develop a bond that motivates them to remain working with the team more like a family. They conduct SCRUMs, work together, lunch together, and socialize outside the workplace. As a result, they are more inclined to help one another by putting in the extra effort to not let the rest of the team down in achieving the milestones of the initiative.
I too have worked in the past with consolidated resources who participated in SCRUM calls with the team members of initiatives on which they participated; the two are not mutually exclusive. An architect can be dedicated or not dedicated to a particular initiative and still be part of the team, befriending team members in and out of the office. An additional advantage for an architect to have when belonging to a consolidated architecture group is that they then feel that they have support of the architecture community, and that are now able to more readily leverage the knowledge and work of their teammates so as not to risk the possibility of reinventing the wheel.
3. When the same individuals dedicate large amounts of their time and effort on developing something, they develop a sense of pride and ownership. The team in Apple that developed the iPhone did it because they were emotionally bound to their team and the initiative, as well as the opportunity to be successful for such a historic visionary as the legendary Steve Jobs.
Good point, though I believe Apple has centralized enterprise architecture.
In the now famous story* when the iPhone was six weeks from deployment, Steve Jobs placed his iPhone in his pocket and realized that the screens were easily scratched by keys. Apple had to scramble to identify a superior material for their screens and then they had to pay to have nearly a million phones refitted, reentering and disrupting a step of the manufacturing process.
To continue your analogy, Apple does show that having a project focus works well, after all, they did build the iPhone. However, they could have greatly benefitted from better internal standards and governance to prevent the tunnel vision of dedicated teams such as the one that selected the initial glass component.
4. It becomes possible to establish a shared vision among a team when the members of the team are not rolled in and out as needed.
The manager can indeed help both dedicated and non-dedicated team members receive the vision of the manager; we would expect them to take their vision from the team they are participating in. That said, I would point out that the Enterprise vision is just as important here, and I expect architects to take that vision to each initiative they participate in. We would not want someone building a work of art that is in conflict with the vision of the initiative or not compliant with Enterprise standards.
5. Familiarity with an initiative can help foster innovation instead of hampering the creativity of individuals by allowing them the opportunity to amass the level of knowledge necessary for innovations to occur.
Familiarity with just one initiative versus multiple initiatives and architectural disciplines would appear to give the advantage to the latter. Also, the potential for innovations that are global in nature would probably deliver greater competitive value.
6. A consolidated architecture team requires a complex matrix organization with architects reporting to the central architecture organization as well as to the management of each initiative they support.
The matrix organization model has been used extensively throughout several industries, including our own. As such, I am not certain of the conflict you foresee.
Let’s imagine a homeowner is installing a solar array in their backyard to generate their power requirements. They remain attached to the grid so that you can bank the excess power you generate during the day, which they may draw upon at night, thereby netting their electric bill to zero. However, when the first neighborhood blackout occurs during the day they realize that the installer designed the solar system to automatically shut down when the power grid was down. However, the homeowner prefers to have the solar array power their home even when the grid is down. Although the installer who works for the homeowner can make the change, it violates the building codes of the state and local building department.
Since the licensed electrician refuses to violate the building code, let’s say the homeowner then hires an unlicensed electrician to do the work. At some point in the future the grid goes down and unbeknownst to anyone else, the home now has uninterrupted power from the solar array. This appears quite advantageous for the homeowner.
At some point the electric company sends out a repair crew to fix the lines that were downed due to a fallen tree. The repairman knows that the power company has the power shutdown from their side, however the power company’s repairman receives injuries from the power traveling from the opposite direction because someone’s solar array was connected to the grid and did not shutdown automatically as required. As a result, the repairman loses income, the power company faces increased insurance premiums, the healthcare provider of the repairman faces costs associated with delivering medical services, the homeowner faces fines and civil penalties, and the unlicensed electrician faces civil and criminal charges.
Analogously, architectural standards are developed with the objective of controlling costs across the enterprise. Each initiative will be receiving the equivalent of “licensed” architects who will be responsible for enterprise architecture standards compliance, with a process in place to request exceptions. If an exception does not violate the interests of another stakeholder, and is clearly advantageous cost-wise over the potential life of the design, then simply put, the exception will be eagerly approved.
7. Having multiple masters creates confusion and reduces an individual’s focus on the priorities of each manager.
The use of the matrix organization model has been around for so long, that those who are senior enough to be enterprise architects have been there and done that.
8. Practice groups or centers of excellence provide a better alternative to a consolidated architecture group.
Practice groups are better than nothing, but not the same as having a centralized group where cross training and collaboration across architectural disciplines is the norm rather than the exception. More importantly, practice groups do not actively ensure that initiatives do not inadvertently violate the interests of another stakeholder.
9. Attaining consensus on a team with staff rotating in and out is more time consuming, which would be highly detrimental to an initiative with an aggressive schedule to meet business needs.
My priority is to provide business value. To go back to your iPhone analogy, Steve Jobs wanted that iPhone built quickly. But it wouldn’t do anyone any good if the iPhone was delivered to consumers and didn’t comply with FCC regulations, the US power grid, or had a screen that was easily scratched.
Likewise, our architecture team must be able to respond quickly to changing events in order to incorporate changing business priorities, rapidly evolving technologies, and improved frameworks that could provide us a competitive advantage.
10. Splitting responsibility and authority between a centralized architecture group and initiative management causes the initiative manager to have responsibility for schedules and budgets without authority to drive the team to achieve the objectives of the initiative. Likewise, centralized architecture has authority over architects, but lacks control over schedules and budgets.
Various stakeholders exist across the organization. It is part of our job is to keep our stakeholders informed and to follow their standards The engineer that complains about serving multiple masters must recognize that our efforts are only useful if we operate while protecting the interests of our corporate stakeholders. This means while protecting the company’s brand and reputation, while conforming to legal requirements, such as for records information management (RIM) and legal holds, complying with legislative and regulatory bodies at various jurisdictions ranging from global to local, adhering to customer centric directives as determined by our Chief Customer Officer, and while keeping within their schedule and budget as determined by the initiative manager.
11. Priorities may cause pooled architecture resources to be applied elsewhere in the organization, impacting my initiative.
This is an important point you raise, as when other enterprise objectives receive a higher priority than a particular initiative the impact can be high. That said, if a particular initiative is being starved of resources due to its relative priority then the most appropriate course of action is to address it via the management chain. At the end of the day it is the business’s money we are spending, which our executive management directs us how best to do.
12. If it were intended to give enterprise architecture real authority, then we should probably consider giving it direct responsibilities for enterprise projects upon which it could apply its own standards.
Enterprise architecture does require implementation capabilities for a variety of tactical and strategic activities. This can be accomplished either by having its own tactical application development team or by being aligned with a global application development team that additionally support enterprise architecture.
In addition to the responses to your issues mentioned above, it is important to note that often the best talent within an organization tends to leave due to its being restricted to the scope of one initiative. In contrast, by being part of a team of their peers these individuals are offered a healthy learning curve developing and sharing knowledge, and it becomes more likely for them to stay abreast of industry innovations and frameworks, thereby not requiring them to seek alternate employment to grow.
To briefly summarize our thoughts, a building contractor retains the responsibility and authority from a budgeting and scheduling perspective to build a building. He still has to go to the zoning board for the various permits to ensure that he is compliant with the various stakeholders of the various jurisdictions. Otherwise, you end up driving in Shanghai or Mumbai.
Similarly, a product manager retains the responsibility and authority from a budgeting and scheduling perspective to deliver an initiative. He still has to go to the architecture review board to ensure that he is compliant with the various stakeholders of the various jurisdictions. Otherwise, you end up working at Lehman or a part of AIG that is now owned by MetLife.
In closing, this has been a thought provoking conversation, and I appreciate that you put yourself out there to engage. That said, I should also point out that the rumor that I offered Vladimir a Starbucks gift certificate to ask these specific questions are wholly untrue, although I am certain that we could all agree that he deserves one for putting his thoughts out there.
Thank you and if you have additional concerns I look forward to the pleasure of discussing this further at your convenience.
With warm regards,
Antoinette, Chief Enterprise Architect
Finansiella LTD
Antoinette presses the send button, and moments after, she receives a telephone call on her cell phone from her boss, Jean-Claude, the CIO. Jean-Claude tells her that her response was outstanding, which is a clear indicator of how smart he is for hiring her.
While this author does not take sides in this exchange, it is fair to say that the management style of the new leadership team is such that it would appear Finansiella LTD is becoming an attractive professional environment within which to work.
1.1.3.4.1 Enterprise Architects
It is interesting to contrast the attitudes of enterprise architects who started their career in the 1970s versus the 1980s versus the 1990s and ones who will be starting their careers today. We have observed that these attitudes manifest themselves in the decisions made by the architects that come from these different periods in time. This requires some explanation, since if the problems of EA have optimal solutions, we would expect many enterprise architects to arrive at the same conclusion, irrespective of when they learned their craft. Furthermore, a few decades is not really a significant amount of time.
The generalization does need some qualification. Some of today’s architects do recognize and embrace the fluidity of the technology landscape, economic climate, and marketplace and have been extremely successful. Others, however, do not keep up with change and fail to adapt—sticking to old beliefs and ultimately hurting the enterprises that employ them. This problem can get a lot worse if there is an abundance of like-minded, inflexible personnel—promoting their outdated decisions as well as the ideas of their like-minded colleagues, thereby marginalizing and eliminating those enterprise architects that have embraced change.
The advent of the cloud, social networking, online collaboration, smart phones, and tablets has opened up a world of business opportunities. Cheaper, faster, and more efficient vendors now have a fighting chance against the entrenched IT vendors. Enterprise architects who recognize the benefits of these new technologies can easily outpace their outdated counterparts if they can provide their firms a competitive advantage by maintaining the same level or better level of service at a lower cost.
This is not meant to indicate that the long-established “blue-chip” IT firms do not offer solutions that meet enterprise needs anymore. What it alludes to, however, is that the impediments to the new breed of enterprise architects have taken their toll on the larger IT organizations contributing to their stagnation preventing them from moving away from any of the high price solutions that they acquired prior to more competitive actors entering the marketplace.
While it is true that IT should be making decisions related to technology working as a partner with the business, it is also true that every one of these decisions should provide tangible business benefit. If a technology decision cannot demonstrate a clear benefit to the business, it is certainly a decision that needs further investigation. This link, however, between technology decision making and business benefits is something that has been lost as some IT departments are more guided by the momentum of the past, while in all fairness others are sometimes more guided by the latest unproven solutions that are still in their early stages of hype.
1.1.3.4.2 Role of Enterprise Architecture
The role of enterprise architecture is to develop various frameworks for IT that both facilitate the direction of the business and address major pain points of the business, including representing interests of business stakeholders across the enterprise, such as the legal, compliance, and auditing departments, as well as profit centers and producers, thereby aligning business vision and strategy with IT delivery.
Although rarely stated as such, the mission of enterprise architecture within an organization is to develop the skills, business principles, standards, and frameworks for each architectural discipline necessary to prepare the IT resources of the organization to act effectively to achieve the direction set by the executive leadership team (e.g., CEO, CIO, and Head of Development). The degree of preparedness offsets the cost associated with uncoordinated efforts that have not considered the most effective combination of IT technologies and approach for the use of those technologies.
As such, one of the early and ongoing activities of enterprise architecture is to identify the IT technology areas that are of the greatest importance to the organization at present and in the near future.
Each area is then evaluated to identify:
- which architectural disciplines would be necessary to establish competency in the particular area of technology,
- what the costs would be to establish a reasonable level of competency, and
- an estimation of the immediate, near and long term costs for not managing the particular area of technology.
Due to the low cost structures, typical of enterprise architecture departments, enterprise architecture works behind the scenes in a rather opportunistic manner, to influence the greater environment of automation. Maintaining the preparedness of resources is much like a fitness regimen. One cannot exercise for a number of months and then expect to remain fit for a lifetime.
Although this is an accurate depiction of the intended role, EA in general has a long way to go to get there.
EA had humble beginnings, starting by organizing an inventory of technology products that had been purchased by the enterprise over the years, and by organizing an inventory of application systems that were home grown in-house, home grown but acquired through mergers or acquisitions, purchased and then customized, purchased and left as-is, or licensed as an outsourced service. These inventories, and the methods used to manage them, are referred to as technology portfolio management and application portfolio management, respectively.
Shortly thereafter, senior programmer analysts changed their names to solution architects or application architects, and data modelers changed their names to data or information architects. As we shall soon come to understand, the target state for an enterprise architecture practice that achieves its stated role is quite different in philosophy, taxonomy, organization, and skills. As such, let’s briefly talk philosophy.
1.1.3.4.3 The Hedgehog and the Fox
Philosophy teaches us that there are many ways to view things. The way we think about something right now is certainly not the only way to view that topic.
“The Hedgehog and the Fox” was an essay written by an English philosopher named Isaiah Berlin in 1953, which is based on a fragment originally found written by an ancient Greek poet, Archilochus, circa 650 BC, around 2500 years earlier, which stated, “πόλλ' οἶδ' ἀλώπηξ, ἀλλ' ἐχἐνος ἓν μέγα” (“the fox knows many things, but the hedgehog knows one big thing”).
To paraphrase the story:
The hedgehog is an animal that goes about his business of keeping up his house and dealing with his chores to forage for food. Each day he leaves the safety of his den, chooses the path that will allow him to achieve what he wants to accomplish today, and then returns home. The fox, on the other hand, leaves the comfort of his den and, with a clever mind, searches for opportunities to get his next meal.
The fox knows many things and comes up with clever ideas for how to achieve his goals. When the fox encounters the scent of the hedgehog, he cleverly tracks it back to the den of the hedgehog and plans on following him the next day to make himself a lovely meal.
As planned, the next day the fox sits downwind of the hedgehog’s den waiting, and then right on schedule, watches the hedgehog emerge from the safety of his den, and walks away along one of his favorite paths. The fox follows the hedgehog quietly circling him to be further down the path where the hedgehog must walk through a clearing, where the fox quietly waits anticipating his meal.
When the hedgehog walks deep into the clearing far from cover of foliage the fox charges forward at him. The hedgehog sees the fox and thinks, here he comes again, that silly fox. As the fox rapidly approaches, the hedgehog rolls up into a ball with his quills sticking out all directions around him. The fox quickly screeches to a halt and breaks off the attack, and the hedgehog goes back to his chores.
The End.
This story has been analyzed many times by many great writers and thinkers, and from this story, we learn many things.
First, foxes move on many levels, they are clever and quick, but they never integrate their thinking into a unified vision. The hedgehog, on the other hand, is very smart as well but instead reduces a complex world into simple ideas because they see patterns of what is essential and ignores the rest.
Using this story, we learn the “Hedgehog Concept,” which we will refer to from this point on as we discuss the philosophical differentiators of the new breed of enterprise architecture.
1.1.3.4.4 Philosophical Differentiators
1.1.3.4.4.1 Business Focus
The first philosophical differentiator of modern enterprise architecture is that it starts by integrating strong business knowledge into the enterprise architecture team. A small number of business industry experts render in-depth business knowledge to the group and to the business users they interact with.
With few exceptions of line managers running operational business areas, detailed business knowledge of processes is scarce across the business community. Business users that once knew the business have been replaced by business users who now only understand what information to capture and how. With barely enough time to manage their business operations during the day, the few line managers that know the business have no time for IT, unless of course they desperately need something from them, where the noteworthy word is “desperate.”
Line managers today are among the few that have a need and the interest to read the pertinent business books and legislation. It should also be noted that it would be prohibitively expensive to repopulate the business community with experts in their respective areas of the business.
1.1.3.4.4.2 Development Capabilities
The second philosophical differentiator of the modern enterprise architecture organization is the recognition that it requires access to a development arm, usually either its own adaptive application development team or access to an application development team that supports global initiatives. Without active support from a dynamic application development team, enterprise architecture would be adrift within the organization with no ability to take any action.
1.1.3.4.4.3 Agile Staffing
True for many organizations, the third philosophical differentiator of the true enterprise architecture organization is to maximize flexibility in staffing and taking it to the extreme. Instead of hiring a large staff of full-time employees, staffing is accomplished with temporary consultants that are industry experts within their architectural discipline.
It is critical to establish an expert staff of architects in the pertinent areas with the most immediate needs, such as in BPM technology, workflow automation, information architecture, data obfuscation, data warehousing, content management, and technology portfolio and application portfolio management disciplines. These individuals help build a strong foundation of policies and frameworks that guide the IT and business community. They can always be converted to full-time employees once they have proved themselves, or they can mentor their eventual replacements in the principles, standards, and frameworks that they helped develop.
1.1.3.4.4.4 Synergistic Multipurpose Personnel
The fourth philosophical differentiator of the true EA organization is to adopt the approach with the most modest footprint of staff, such as the use of data stewards within the discipline of data governance. Instead of hiring staff members to support each business department, where possible, select a business knowledgeable individual with interest in enterprise architecture. Training programs must be established to maintain some disciplines anyway, and it is a good practice to engage business users where it can make sense to do so.
1.1.3.4.4.5 Operations Architecture
The fifth philosophical differentiator of the modern enterprise architecture organization is to recognize the distinction between the architectural disciplines associated with information systems architecture and the architectural disciplines that are associated with data center operations. As we shall see, the disciplines associated with operations are quite distinct from those of application and information architecture and are equally necessary.
For example, data center operations include infrastructure architecture, including servers, networks, CITRIX, and thin client architecture; disaster recovery architecture; and data center job scheduling technologies.
1.1.3.4.4.6 Advanced Business Users
The sixth philosophical differentiator of the modern enterprise architecture organization is to recognize that many of today’s business users are tech-savvy, thereby able to form strong opinions on the use of specific tools and technologies. As such, it is imperative that their opinions be respected as well as appropriately challenged. Management on both fronts (IT and Business) must respect dissenting opinions and evaluate solutions strictly on merit and architectural feasibility within a given environment as opposed to considerations of territorial responsibilities.
1.1.3.4.4.7 Self-service Is an Accelerator
The seventh philosophical differentiator of modern enterprise architecture is that business should have as much self-service as possible. Business should not have to fund an ever-increasing inventory of IT staff to generate reports on demand. The new model is for IT to empower the business to be more competitive by encouraging the notion that IT get out of the way of the business, and that the business should take back control of those capabilities that will enhance their competitiveness in the marketplace.
Once business is properly empowered, both sides provide the appropriate checks and balances for the other to act beneficially to the overall enterprise. Business project managers will partner with IT to leverage their architectural knowledge and technology capabilities. Importantly, IT should not be expending resources on initiatives that the business does not understand or agree with as meeting their business objectives.
Part of this is to avoid unrealistic claims of self-service. One of the earliest self-service attempts was the language COBOL. This was designed to consist of terms that were similar to natural languages so that programmers would no longer be needed. Managers and business people could simply write what they needed and when. The result was that by the end of the 1980s, more professional programmers coded in COBOL than in any other language.
1.1.3.4.4.8 Stakeholders Frequently Palaver
The eighth philosophical differentiator of the true enterprise architecture organization is that both business and IT must have representation on the executive leadership team. While business should have representation from finance, business origination, business servicing, business risk management, and compliance, IT should have representation from architecture (enterprise and operations architecture), IT operations, and application services (development and maintenance services).
Using this model, it is important to create and maintain the perception that IT and business are inseparable partners with a shared awareness of business direction and priorities.
1.1.3.4.4.9 Real Transparency not Virtual
The ninth philosophical differentiator of the true EA organization is the presence of a new breed of enterprise architect who recognizes the criticality of IT expense transparency to the business, as well as business expense transparency to IT. Transparency fosters a trusting and cooperative relationship between business and IT and helps ensure that the limited resources of the business are being properly deployed. Transparency also provides insight into the ways that automation can assist the overall enterprise more competitive, and helps keep expenses in check for the activities in both IT and business.
The notion that IT is a financial black hole is about as counterproductive as the notion of business having a shadow IT organization hiding IT resources from IT so that it can get its needs met.
To accomplish expense transparency, business and IT must clearly define each and every initiative in a consistent manner for presentation to a combination of business and IT management for financial and architectural approval.
1.1.3.4.4.10 Business First, Business Second, Business Third
The 10th philosophical differentiator of the true EA organization is that the newest breed of enterprise architect openly confronts the attitude of “entitlement” within IT, trying to position “IT” as resources hired to empower and service “business,” as opposed to “business” being there to simply fund “IT” to fulfill the lifelong dreams of those in IT.
In this new competitive age, IT staff must forge a completely new type of relationship with the business, and IT initiatives must be flexible to address the ability to gain effective and actionable advantage in the competitive marketplace. Including business expertise is not sufficient, as attitudes in IT toward business must change sufficiently to alter relationships. In almost every company, IT doesn’t drive; instead, it enables by making it possible to do more work faster, cheaper, more consistently.
1.1.3.4.4.11 Participators not Spectators
The 11th philosophical differentiator of the true EA organization is that EA can no longer sit back and simply write standards documents and draw pictures that become shelf-ware. EA organizations must now become an integral part of solutions transforming the organization to its desired future state. They must roll up their sleeves and have a handful of strategic projects as a means to directly test their standards and frameworks.
In summary, the new philosophy of enterprise architecture demands a highly dynamic and adaptive team of modern enterprise architects that specialize in the architectural disciplines needed to address the challenges of the business today. The new EA must effectively communicate and educate individuals in both business and IT with strategies and frameworks that focus on the most prominent needs of the business.
In addition, each subject matter expert must have a hedgehog concept that encapsulates the primary mission of each architectural discipline. This hedgehog concept must be simple and easy to remember. We will discuss how to do this in more detail as we get into each architectural discipline.
Every enterprise has access to the same vast selection of technologies and products. That said, it is the new philosophy of EA that will ultimately determine how each enterprise views and coordinates technology to achieve a competitive advantage and meet its goals.
1.1.3.4.5 Taxonomy and Organization of Enterprise Architecture
Today, there are over 50 frameworks that are labeled enterprise architecture frameworks, including those that are openly available at no cost and those that are proprietary for a fee. Depending upon what one uses as a clear sign of when enterprise architecture began, we can say that as a practice it has been around at least with the introduction of The Open Group Architecture Framework (TOGAF) in 1995. To set its origins much earlier one would have to use Zachman as the first sign of enterprise architecture. That said, no matter how much we like Zachman, it has always been a system architecture framework, even though its contents unchanged were later relabeled or rebranded for marketing purposes as an enterprise architecture framework when EA as a term came into fashion.
Enterprise architecture is no longer your predecessor’s view of enterprise architecture, which is a good thing as that prior view did little to change the industry over the past 15 years. A medical analogy may be useful. In bygone days, the majority of medical practitioners were general practitioners, pharmacists, and so on. Today, we have far more specializations than previously, in areas such as immunology, anesthesiology, dermatology, and more depending upon the size and type of hospital in which these personnel work. Similarly, EA must specialize to meet the challenges of the modern world.
To organize EA into its distinct architectural disciplines, there are six major areas that comprise the specific architectural disciplines, which technically include their governance so that there is a way to ensure that they achieve their objectives in an efficient and measurable way. These are:
- “business” architecture,
- “information systems” architecture,
- “information” architecture,
- “control systems” architecture,
- “operations” architecture, and
- “cross architecture disciplines.”
We should reiterate that there is sufficient material for any of the topics within these five major areas of enterprise architecture to warrant their own book. However, it is only our intent to communicate the complete architectural framework of modern EA for enterprises with enough detail to understand what it does, why it is important, and to imply what the cost to the enterprise may be if it elected to leave a particular architectural discipline unmanaged.
DIAGRAM Enterprise architecture overview.
* (Business Insider, Tech, “Steve Jobs Freaked Out a Month Before First iPhone Was Released and Demanded a New Screen”, Henry Blodget, January 22, 2012).