Enterprise Architecture: Part two

On June 5, 2013 we introduced Enterprise Architecture on this blog. That first introduction article came on the heels of the Enterprise Architecture Working Group that ran parallel to the IT Strategic Plan. As the IST Director, Enterprise Architecture I will continue exploring the topic of Enterprise Architecture (EA) as we steadily bootstrap an EA Program here at Waterloo.

This article is drawn from materials I will be presenting along with another presenter at Ontario Connections 2014 (http://www.ontarioconnections.ca/).

Architecture, isn’t that for buildings?

Since assuming my role I have found myself answering that question on numerous occasions.

I have found one of the best ways to explain Enterprise Architecture (EA) and to help people understand what it is about is to use an analogy to the topic people have pointed to—building (physical) architecture.  If we look for patterns between physical architecture and enterprise architecture we can build on this analogy to help people understand.

Whenever an individual starts a physical architecture project (whether a skyscraper or kitchen renovation), they first start with a high-level statement of the inputs, needs, goals, and target outputs.  For this example analogy I will us a kitchen renovation project.  These needs, inputs, goals, and target outputs often manifest themselves as simple lists.

What do they need for the kitchen?  What is important to them?
  • Marble counters
  • Top-end fixtures
  • Cork floors
How will they use the kitchen?
  • Chopping needs
  • Small appliance needs (blending, stand mixer)
  • Socializing with friends and family
  • Quick “on-the-go” breakfast
Where do they do different things in the kitchen (sink, island, stove)?
  • Fridge and stove must be by power/water/gas supplies
  • Chopping next to sink
  • Sitting area and dining area
Who will use the new kitchen?  Who needs to do the work on it?
  • Owners
  • Friends
  • Family
  • Contractors
  • Inspectors
When can they work on it?  When do they need it completed?
  • Important holidays
  • Critical periods where they can not be without a kitchen
Why are they spending the money / effort to make these changes?
  • Investment in value of home
  • Status symbol
  • Be a popular place for gathering

We ask these same questions when thinking about Enterprise Architecture.

What is important in the production of goods and services that Waterloo produces?
  • List of things important to the business => Material List
How does the University of Waterloo work?  How do we work together?
  • List of processes the business performs => Process List
Where are these goods and services produced and consumed?
  • List of locations in which the business operates => Locations List
Who is involved in the production and consumption of Waterloo outputs?
  • List of organizations/agents important to the business => Stakeholder List
When are these goods and services produced?  When are they required?
  • List of events significant to the business => Events / Cycles List
Why does the University of Waterloo exist?  Why are they expending resources?
  • List of business goals / strategies => Strategic Plans

As these lists are produced we are painting a picture of the current state with a view towards a future state we wish to attain.  At various levels of detail (abstraction), architects capture current state and envision future state.  They work down towards detailed specifications from these high-level lists.

While working down towards detailed specifications, architects often rely on Subject Matter Experts [SMEs] (also sometimes called Domain Experts).  While an architect often can do much of the work required, it is better to rely on experts working in a particular field because an architect’s knowledge is usually academic in nature (missing expertise and context from practitioners).

To continue with the analogy from above we can identify similar fields between physical architecture and enterprise architecture.

Plumbing

Network infrastructure

Electrical

Computing infrastructure

Carpentry and finishing

Applications infrastructure

Accessibility design and landscaping

User interface / User experience design

With specialists from these areas, architects work to assemble documentation and diagrams (models) to capture detail about current state and plan towards a future state.  Once this is assembled, organized, and cross-referenced the work of building can commence.

Why is EA important?

To understand why we are building an Enterprise Architecture (EA) practice at Waterloo, we must contemplate one of the biggest problems EA is trying to address—Enterprises are incredibly complex entities.

  1. There are many inputs to an enterprise.  They must adapt to the environment they operate in, the strategic context they exist in, and the strategic drivers guiding them.
  2. There are many components to an enterprise.  This is often summarized as “people, processes, and technology.”  All these components must work together in harmony for the enterprise to maximize efficiency and effectiveness.
  3. Change is constant.  Day-to-day, week-to-week, month-to-month, and year-to-year an enterprise is always changing.  The reasons for this change are diverse but you can learn more about the underpinnings of this reality by exploring the field of Complexity and Complex Adaptive Systems (CAS).

To account for the reality of enterprise complexity we turn to a tried, tested, and true approach-- we divide and conquer!  This is why, as discussed in the building analogy, we rely on a number of different experts from different areas (domains).  We must divide.  This is the first component of the approach.

Once we have divided the problem between experts we can start conquering this complexity. We start by re-integrating the various diagrams (models) into one place.  From this single source we can cross-reference and allow select groups of subject matter experts to review the ‘current’ state and the ‘future’ state (identifying gaps).  In the kitchen analogy this is akin to the city permits office reviewing your subcontractors (plumbers, electricians, carpenters) plans and noting gaps demanded by local building codes.  In EA we tend to use a Core Review Team or an Architectural Review Board to help us understand current applications, the underlying technologies, and the capabilities required to live up to our ‘code’ (the university strategy).

Keep watching this blog for the next part of this series where we will dig deeper into the tools we intend to use to conquer this complexity.  We will discuss domains, frameworks, review processes, and the importance of a repository for holding it all together.

Thanks to our guest blogger, Colin Bell.

  1. 2019 (5)
    1. December (1)
    2. November (2)
    3. August (1)
    4. July (1)
  2. 2018 (6)
    1. October (2)
    2. July (2)
    3. April (1)
    4. January (1)
  3. 2017 (2)
    1. November (1)
    2. October (1)
  4. 2016 (4)
    1. September (1)
    2. July (3)
  5. 2015 (13)
    1. October (1)
    2. August (1)
    3. July (1)
    4. June (1)
    5. May (2)
    6. April (2)
    7. March (2)
    8. February (3)
  6. 2014 (11)
    1. December (2)
    2. May (2)
    3. April (2)
    4. March (2)
    5. February (2)
    6. January (1)
  7. 2013 (23)
    1. December (1)
    2. November (2)
    3. October (3)
    4. September (2)
    5. August (2)
    6. July (5)
    7. June (4)
    8. May (4)