The differences in internal controls at each level of architecture

Welcome back. We have arrived as noted in my opening IT World post at the point where, expert Matthew Kern will share a new paper on EA and help us consider differences in internal controls at each level of architecture.

As you might have anticipated, this is actually the beginning of a series of posts intended to progressively achieve that objective and eventually provide a link to the related paper. To kick-off this series we begin with the following provided by Matt to help us establish a common foundation for moving forward through incremental posts. My thanks to Matt for work on this series, and to you the reader for following along.

What is enterprise architecture (EA)?  This topic has generated a huge range of argument, debate and discourse. A lack of clarity has confused customers, recruiters, service providers and policy makers. To clarify this enterprise architecture has been divided into viewpoints (All, Data, Capability, Operational, Service, Systems, and Project), domains (business architecture, data architecture, applications architecture, and technology architecture), levels (enterprise, segment, solution). Enterprise architecture has been placed in cubes, matrices and sequences. In this post we will concentrate on what specific business processes we refer to when we say “enterprise architecture.”

Where might we begin? At the risk of stating the obvious, enterprise architecture is support to management. It is not the CEO, it is not the project manager, it supports them. Let’s examine which types of management enterprise architecture supports.

The PMBOK (Project Management Body of Knowledge), Fifth Edition, is an ANSI standard for project management and is associated with a very popular certification (Project Management Professional) here in North America. The PMBOK says nothing about enterprise architecture, but says many authoritative things about management and how to practice it.The PMBOK divides management into operational management and transformational management.

“Operations management is an area of management concerned with ongoing production of goods and/or services. It involves ensuring that business operations continue efficiently by using the optimum resources needed and meeting customer demands. It is concerned with managing processes that transform inputs (e.g., materials, components, energy, and labor) into outputs (e.g., products, goods and or services).” PMBOK Guide, Fifth Edition, 2013, pp 13.

And also:

“Operations management is a subject that is outside the scope of formal project management as described in this standard.” PMBOK Guide, Fifth Edition, 2013, pp 13.

Enterprise architecture is most often associated with transformation. We may ignore operational management for the moment, and focus on transformational management. If operational management ever changes (transforms) and requires a new architecture, it becomes transformational management of some type.

There are three types or levels of transformational management described in the PMBOK:

“Portfolio, program and project management are aligned with or driven by organizational strategies. Conversely portfolio, program and project management differ in the ways each contributes to strategic goals. Portfolio management aligns with organizational strategies by selecting the right programs or projects, prioritizing the work, and providing the needed resources, whereas program management harmonizes its projects and program components and controls interdependencies in order to realize specified benefits. Project management develops and implements plans to achieve a specific scope that is driven by the objectives of the program or portfolio it is subjected to and, ultimately, organizational strategies…“ PMBOK Guide, Fifth Edition, 2013, pp 7.

Enterprise architecture, a transformational activity, must support one or more of these three types of management. If we want a comprehensive answer, we can say it supports all three. This approach is not new.  Richard Burk at the United States Office of Management and Budget asserted the same thing in 2006.

Three levels of EA in OMB FEA Practice Guidance from Burke

Figure 1  Three levels of EA in OMB FEA Practice Guidance, from Burk.

Putting this together so we achieve the clarity we desire:

  • Enterprise architecture supports portfolio management. It is that architecture process that supports the portfolio manager.
  • Segment architecture supports program management. It is that architecture process that supports the program manager.
  • Solution (sometimes system) architecture supports project management. It is that architectural process that supports the project manager.

The next post in this series will share awareness of two missing enterprise architecture processes that manage continuous improvement, and assure alignment between levels to achieve strategic goals.

Would you recommend this article?

Share

Thanks for taking the time to let us know what you think of this article!
We'd love to hear your opinion about this or any other story you read in our publication.


Jim Love, Chief Content Officer, IT World Canada
Ron Richard
Ron Richardhttp://www.inherentquality.com
Ron Richard, Quality, Information Technology and Enterprise Risk Management specialist, has earned professional designations from multiple countries, held positions at most any level, and acquired more than 30 years of relevant experience including related work done at the College of the North Atlantic. Ron is author of Inherent Quality Simplicity and the Inside Internal Control newsletter Modern Quality Management series.

Featured Download

IT World Canada in your inbox

Our experienced team of journalists and bloggers bring you engaging in-depth interviews, videos and content targeted to IT professionals and line-of-business executives.

Latest Blogs

Senior Contributor Spotlight