Enterprise Architecture : An Introduction

As a budding Enterprise Architect, I’ve always been interested in the bigger picture when it comes to how an organization plans, executes and maintains its IT infrastructure.  Before we jump into what Enterprise Architecture is as a concept, we need to understand why IT is such an important function of any operating organization and reiterate why IT remains the back bone of a business.

Information Technology in the eyes of an organization is one of its Strategic Assets. Assets are a businesses economic resource (something owned that has material value) that for the most part adds value.  Organizations deploy this asset in supporting the business via new technology / development and the day to day task of running the IT ‘engine’.  An example of where IT supports the business would be the availability and advanced analyzing of sales or marketing data that can make or break a business decision and which could ultimatley effect the businesses position in the market.  What is important to remember here is that the goal of any business or organization or division or department is never fixed.  Goals of all sizes are moving targets and so the IT infrastructure that supports that business/organization must continue to improve and grow to support these goals.

A quick tour through the IT generations

IT didn’t just appear as a business function overnight, it developed through generations of supporting business processes. Here is a quick look at the story so far:

First Generation IT (G1) – Developed in the 70’s to support ‘batch based’ business processes. Batch based processing was a collection of automated series of programs (jobs) that had no human intervention. Batch based computing mainly occurred on main frame computing environments.

Second Generation IT (G2) – Emerging through the late 80’s to early 90’s was ‘Closed Multitask computing’ where programs could individually run threads of processing at the same time. This period saw the advent of Windows.

Third Generation IT (G3) – Emerging in the mid 90’s this period saw the ‘connected’, online accessibility era. The face of the business became the web site and new business models were born.

Fourth Generation IT (G4) – 2000 – The ubiquitous (everywhere), always connected service based architecture that IT departments strive for today.

Fifth Generation IT (G5) – 2015+ (who knows?)

As businesses move between these generations of change, massive IT infrastructure investments are made.  A good example to follow how business processes have changed throughout the generations is to look at the Banking sector.  In the 70’s you could only perform your banking duties between certain hours on certain days of the week and you had to go visit a physical branch.  Transactions where processed in batches on a day to day basis and statement printing was also carried out in batches so you would only know how much money you had on a monthly basis.  Today, banks offer global access to your money, statements and global online trading has changed the face of investments.  All of your banking information is available in one of two places, 1) via your personalised internet banking web portal and 2) via global ATM network.

Because of these continual improvements to banking IT infrastructure over the years, banks are thriving as a business and essentially run the cities of the world with their cash (except when the government / tax payer has to bail them out because of a global recession of course, but let’s not focus on that 😉

So What is Enterprise Architecture

Enterprise Architecture is one of those subjects that can easily invoke tongue twisting. The official ANSI/IEEE definition of EA is :

“the fundamental organization of a system, embodied in its component objects, their relationships to each other, the environment in which the objects reside and the principles governing the systems design and evolution”.

Makes sense right?  The Metaphor would be the design of a city (think Sim City).  The architectural blue print details the roads, utilities, open spaces (parks) and their locations / interactions.  Using this example utilities are the technologies and frameworks employed,  roads provide the communication and networks and the open spaces / parks are the applications and systems and how they interact with each other.

Whats the goal of enterprise architecture then?

It’s important not just to pass the definition of Enterprise Architecture without mentioning the ultimate goal of Enterprise Architecture.  The goal is to create a unified IT environment (so common hardware, platforms and technologies using open/common standards), create an alignment of the technology with the business, to make use of or ‘re-use’ existing IT assets and finally, promote the sharing of project management / software design approaches across the enterprise.  The end result at least in theory is that the Enterprise Architecture (blueprint, roadmap etc) will make IT investment cheaper, make IT more strategic, and ensure IT is more responsive to
business change.

Enterprise Architecture has 4 basic domains (according to most EA frameworks):

Business Architecture – Documentation that outlines the company’s most important / business critical processes (the most critical domain but also the most difficult to implement)

Information Architecture – Identifies where important blocks of information such as a customers data are kept and how that data is accessed.

Application System Architecture – A map of the relationships of software applications to one another.

Technology Infrastructure Architecture – The blueprint for the hardware, storage systems, and networks.

In terms of skill sets for the aspiring Enterprise Architect :

(1) Business Process Modelling, Design, Re-Engineering (BPMN, BPEL, BPM Servers)
(2) Database Administrator / Designer (SQL, LinQ, Database Design, RDBMS)
(3) Software Developer / Architect and Enterprise Integration techniques (Middleware, API, Software Dev Platforms / Frameworks)
(4) Network and Hardware specialist (Servers, Common Server Roles, Network Stack incl Protocols, Topology planning, Operating Systems, Hardware)

Breaking the Enterprise Architecture down

An enterprise is a whole corporation, a division of a corporation, a government agency, a single department, or a network of geographically distant organizations linked together by a common business goal / objective.
Enterprise architecture relates to understanding the collection of child business entities/objects that comprise one of the above enterprise definitions and how those elements interrelate.

Enterprise architecture =

Business Processes       + Applications       + Technologies        + Data

People                                          Systems                        Communications          Information
Processes                                    Software                       Services
Business Drivers

An architecture is blue printed
A road map plans the delivery of that architecture

A quick note on Governance

The primary purpose of enterprise architecture governance is to ensure that an organization’s IT investments are closely aligned with business goals and processes, so that limited IT resources are allocated to areas of highest impact on organizational performance. Enterprise Architecture governance has its own framework but we won’t get into that now.

Enterprise Architecture Frameworks

Layered frameworks and models for enterprise architecture have proved useful because layering has the advantage of defining contained, non-overlapping partitions of the environment. There is a number of models/modeling techniques, the top 5 most common follow:

1. Zachman Enterprise Architecture Framework (ZIFA or just Zachman)
2. The Open Group Architecture Framework (TOGAF)
3. Extended Enterprise Architecture Framework (E2AF)
4. Enterprise Architecture Planning (EAP)
5. Federal Enterprise Architecture Framework (FEAF)

All of these models seek in one form or another to make use of the concept of a generic service/object-oriented architecture where sets of like functions are grouped into reusable services that can be described as ‘service objects’. More complex capabilities are then built from a combination of these basic service objects just as the elements are made of atoms. For now we’ll leave the discussion of Enterprise Architecture here and come back and discuss a couple of these Enterprise Architecture frameworks in separate articles.

Hopefully this has wet the taste buds for the bigger Enterprise Architecture picture.