Discipline Maturity Lifecycle: Enterprsie Architecture example

Spent this morning thinking about operating models in IT organizations and ITIL initiatives.   After a few minutes of pondering , hearing a group next to me at a conference extol the virtues of the 4hr days a few thoughts came back to me; the IT discipline is still in a low state of maturity.  If I was to use a human scale, the IT discipline is like a 5 year old copying its older brothers thinking it is all grown up.  Sure the IT Discipline has many elements that other more mature design and development disciplines have, however, the behavior, standards, ethics and other aspects around the profession have yet to develop.

This revelation is not new to me, years ago I had started quantifying how other design disciplines evolved and matured.  I had presented a corkscrew diagram at some conference back then and left it as an interesting phenomena.  As I was in a keynote session the image popped back in my mind and the book I had started but never finished.

What triggered that thought process was a discussion of the Enterprise Architecture discipline/practice.  This had triggered another memory of drafting a paper and proposal to create “The Architect’s Office” within an IT Organization I was working in.  Some of the issues are still the same which were taken from my studies in residential architecture and later field experience:  Architectural Practice is not like Howard Roark in Anne Rand’s The Fountainhead the majority of the time.  It is a social and community effort.

There are two aspects to successful architectural firms:

  • The Practice BOK –the body of knowledge and activities used to perform and deliver value to the client.  This is where most practitioners focus when discussing the discipline.  The mechanics of deliverable creation.   While this is the      foundation of any discipline and it grows as it matures, it is only part of the practice.  Many EA firms have yet to take that jump into operating the discipline as a business as opposed to only a methodology of delivery.
  • The Business –the selection of market, the value defined to be delivered, and the means on how value controlled and delivered (aka the Business Model).   Without knowing your business model Enterprise Architectures are prone to produce limited value to customers though providing what was requested.       Eventually, the practice could end up in a different business or on the corner with a sign “will architect for food” as the activities performed do not deliver an acceptable cost benefit ratio to  clients. This suggests that architects need to understand their market and alternatives to their delivery of value.       Many residential architects left the calling in the 70s & 80s as customers failed to see the value they provided over general contractors that had draftsman on staff.

Governance Visualization

Reading Enterprise Architecture -creating value by informed governance.   The one take-away I’ve gotten so far from the book has been confirmation of Stafford Beer VSM’s concepts: the recognition that management and control within an enterprise need to be designed with the same discipline and rigor or more that are used for products and services.

Designing effective governance directly effects an enterprise’s ability.  In an environment and economy that demands that enterprises be flexible, adaptive, efficient and effective, having the appropriate governance system is a critical enabling factor.  Some of the spectacular business failures of the past decades have not been failures of product, production process or services.  These failures have been lapses of effective governance.  This goes beyond the financial and ethical scandals that have brought about SOX legislation.   One only needs to look at the issues that the US Government is going through.  Almost everyone is looking towards the government with frustration and wondering why it does not appear to be working or unable to get things done.  A simple look indicates a failure of governance by the very body that has been delegated that responsibility.   I bring these circumstances and events up as proof-points to my original premise; management and control have gotten complex enough in today’s environment that governance needs to be designed and built.

If I haven’t lost you reading this you’re asking now what?  What do I do if I buy your premise?  As an Enterprise Architect, the next step appears simple but is quiet hard: recognize that governance is a subsystem in the enterprise which is a system in the environment.  Usually Enterprise Architects spend significant time articulating how the value creation process is exposed by a product or service system.   Or Infrastructure Architects focus on creating the information system that enables or embodies this creation process.   However, the sub-discipline and practice of governance creation is still emerging as a practice within Enterprise Architecture.

The diagrams below are but one visualization method on how governance can be displayed.  While overly simplified, I find this method clear and concise to communicate in a less jargon filled discussion.  The first diagram illustrates how the management system aka governance reacts with both the environment and operations.  The management senses the environment and operations and sends control instructions to operations to adjust to environmental needs.  In this context environment is the ecosystem that the business operates within.

In this second illustration the system is diagramed in more detail showing how the management system is partitioned is to sub-control activities and the mechanisms (triangles) used to coordinate activities.   This does not take the place of business rules, charters, and other textual representations of governance, however, it does enable visualization on how the components interact as well as help identify gaps in governance.


Enterprise I.T. Strategy and Governance Vacuum

Over the past two years I’ve been observing the dialog within the SharePoint community around governance.   There are hints that the community is evolving as several people are now discussing the role of business in governance.   This discussion was missing during initial treatments of the topic at conferences I attended.  It was emblematic of the IT community as a whole during the past decade.

Much of the focus of IT governance has been on execution of permissions for access to information or applications.  While this is important and the end goal of governance, this is the equivalent of law enforcement more so than actual governance which is the process by which decisions on access is made.  IT organizations have become surrogate business asset management boards and in some cases the role has been pushed down to the lowest levels of IT.  A natural result of such unrestrained delegation has been this focus on execution with the decisions on who and how information assess becomes an ad hoc process or left to those that build but do not use the systems.

IT Catch-22

These factors have left IT organizations frustrated as the businesses as they serve.  IT organizations are either blamed for not “just taking care of it” or being “too arrogant, bureaucratic, unresponsive and out of touch with business needs”.  IT Leaders are not complacent about this situation, but confused as to how to address it.  Candid discussions the past two weeks with several organizations facing these challenges confirm this.


If an IT organization attempts to just take care of managing an enterprise’s information it faces the challenge of understanding what information is needed, who needs access, how it is to be used, and a variety of other attributes for this information.  All this and then attaining agreement and adoption from the business community.  This is a tall order for a organization that has spent the majority of its efforts on deploying and maintaining technology.  One only need look at IT group budgets over the years to understand where its capabilities and competencies lay.  One could blame MIS directors and CIOs for this however, this is what they were missioned and incented to achieve throughout the past decades.  The typical IT Executives had been constantly receiving directions to lower costs of the infrastructure, increase capacity, and maintain the current technology.  If one looks at IT Industry focus over the past several decades aside from the technology generations the one initiative that stands out is TCO, Total Cost of Ownership.

Doing the same thing and expecting a different result…

When management consulting started to address Information Technology management it has continually put its efforts into optimization of existing resources.  This is equivalent to efforts that these firms put toward manufacturing hard goods products.  The thoughts behind doing so was that human labor was cheap but equipment was expensive.  So methods such as operations research to cut idle time through scheduling and a limited version of portfolio management meant to reduce capital holdings became the prevailing wisdom of the day.  Most enterprises unaware that the paradigm of work was changing from expensive equipment to expensive labor accepted this IT strategy.  During the 80s human resources became more expensive than physical resources, however, the management strategies and techniques have not kept pace with this reality in most enterprises.

Acceptance of this old strategy has meant that over time enterprises and IT organizations as a result, spent what resources not devoted to technology deployment and maintenance to developing competence on cost management or cutting.  The areas of information strategy and architecture that had started in parallel were gradually thinned out, demoted and discounted as the orders of the day was cost management.  Enterprises had by default outsourced their information management strategy to vendors.  Those that disagree with this assessment can look no further than the details of most technology strategy groups within IT functions and see the primary activity is around technology purchase, deployment, maintenance optimization.   Very little investment has been put forth on developing information management verses information technology capabilities.  Of the fifteen organizations I’ve surveyed the past two months, all had Portfolio Management initiatives with a mission on reduction of application and hardware investments, only two had just the start a practice for the management of information as an asset and both are struggling with understanding how to ensure alignment with business.

This is not a condemnation of enterprise management, management consulting or the IT organizations.  This is just a reporting of what I’ve seen over the decades as someone who has cycle through multiple  functions within the business and multiple organizations.  The circumstances, the decisions and actions made have resulted into the situation enterprises are in today.  Like issues with the US Economy or the Environment these are results from the build up of small effects over a long period of time.  Long horizon effects is something that most people and therefore organizations are not well suited to address, especially with the instant gratification culture we’ve developed into today.    So it should not be unexpected that managing information –a new discipline — has not developed as a competency in the business side or IT.

 I’m going to show them … a world without rules or controls, borders or boundaries. A world where anything is possible. Where we go from there is a choice I leave to you

Where does that leave business and IT?  Businesses need to reexamine their role in managing information.  I say information specifically not information technology.  Business members cannot delegate the responsibility to manage their information.  Abdicating control over this critical component results in losing control of the business itself.  For IT figuring out how to partner with the business to address complex issues is key.  Discussing EA with my fifteen IT organizations and on LinkedIn CIO Network forum the questions I’m repeatedly asked is “how?”.  How do we partner with business?  How do we get business engaged with information/technology decision issues?  Senior and technical leadership within IT organizations asking these questions does not suggest arrogance to me.  IT’s focus on IT specific issues without linkage to the  business paradigm and goals suggests a blindness or one dimensional quality which can be seen as arrogance by other disciplines in the enterprise.

I don’t have a magic formula for Business-IT engagement other than to open a dialog.  However, for dialog to occur a common language or effective translation needs to occur.  IT organizations need to develop an understanding of business and the means to translate business concepts into IT execution.  This is more than just a word for word translation but an active exchange where concepts such as business models are investigated for IT enablement options, the alternatives are relayed back to enterprise executives and line of business management as well as the consequences of choosing an alternative from a business perspective so joint decisions can be made.  This model of engagement is not new to industrial enterprises.  Marketing, Engineering, and Manufacturing now team on making decisions in most leading corporations since the 80s under the banner of concurrent engineering.   This is focused upon decisions about products and goods sold.  Today as products and services include IT components, IT organizations should be prepared to “participate” not direct in these teams.  Likewise IT needs to prepare itself to discuss business strategy, organization and operations on more than just a technology thread.  Failure to be able to converse on content beyond IT will continue to relegate the IT organization as a suspected subordinate function.

How this effects Enterprise Strategy and IT Governance?  Without the executive and line of business management participating in governance as full members the IT organizations will always be viewed as autocratic and detached from the business.  IT organizations need to prepare, educate, and reach out to other’s as a colleagues.

Enterprise Architecture Discipline Classification

Like the discipline of Physics which has multiple branches of practice, so too Enterprise Architecture should distinguish branches of practices such as Theoretical and Applied Enterprise Architecture.

In Physics: Applied physics is a general term for physics research which is intended for a particular use. An applied physics curriculum usually contains a few classes in an applied discipline, like geology or electrical engineering. While

Theoretical physics is a branch of physics which employs mathematical models and abstractions of physics to rationalize, explain and predict natural phenomena. The importance of mathematics in theoretical physics is sometimes emphasized by expression “mathematical physics“.[note 1]

The advancement of science depends in general on the interplay between experimental studies and theory. In some cases, theoretical physics adheres to standards of mathematical rigor while giving little weight to experiments and observations.

Again like Physics, the partitioning of the discipline into categories will likely require a richer taxonomy that the current hierarchy in use today which has its basis from the Zachman Framework.   This does not mean that the Zachman Framework and derivatives from it are invalid views.  However, looking at the Framework from a broader perspective may yield a more comprehensive ontology that could fill in the gaps between business theory and I.T. design and executional elements.

Today, as I continue my research in the arena I was watching various Black Hole and Physics programs on the Science Channel.  As I listened to some of the arguments and history regarding Black Holes and the physics behind these discussions it sounded much like some of the discussions I’ve heard over the years and more recently in the Google Group Enterprise Architecture Forum.   All of these ranged around what should be or not be in Enterprise Architecture verses Information Technology or Infrastructure Architecture.  The various sides all wish to include or exclude various areas such as BPR or I.T. and its subdivisions or business models or finance.  Add to that the difference between theoretical and applied ad EA is a mélange of sub-disciplines that are still to be related together into a cogent body of knowledge.

While initiatives such as TOGAF are attempting to amass a body on knowledge what I’ve seen is an orientation that still approaches the topic from a strictly I.T. perspective, projecting into the business domain from that orientation.  This has the effect to limit the non-I.T. contributions that are, in my opinion, just has valuable.  Business Models and Strategy, Organizational Design and other areas all have a contribution to the “Architecture” of an enterprise and therefore should be included in such a discipline.

As initiatives such collaboration and social networks gain importance so too shall these other soft sciences and sub-disciplines increase in priority and influence in how an enterprise is structured and operates.  That suggests that these are architecture components for enterprise, like light and space are architecture components in dwelling architecture.

The Meta-Framework for discipline definition I proposed prior a approximately decade ago at ZIFA was Jon Lang’s used in the field of Dwelling architecture. This does not replace the Zachman Framework but places a context for it to operate in to help distinguish between theoretical and applied, prescriptive and descriptive.

Translating Business to Enterprise Architecture: Methodology Activity #4

Portfolio Decision Making Methods

The process by which alignment occurs in organizations is never a simple activity.  While it would be great to have a mathematical formula that generates enterprise architecture from business strategy, the fact of the matter is that there is no one right answer that fit for all.  Having business strategy x does not always translate to enterprise architecture y.    

The alignment of Business Strategy and Enterprise Architecture resembles algebra or calculus more than simple addition.  The areas that have yielded promise:  multi-variant analysis, Real Options (a derivative of options theory); Bayesian models, and quality function deployment.  If this appears to be a short course in decision science it is. 

In the 80s Marylyn Parker et al, at the IBM Los Angeles Scientific Center developed a methodology, BEAM, which guided MIS directors on the prioritization of I.T. investments.  If it was created today it would likely be called Balance Scorecard for I.T.  Unfortunately the timing was not right for acceptance of this approach, nor was access to corporate strategy or decision authority granted at the senior MIS levels.  But that doesn’t make it less useful today.  The heart of BEAM is using multiple weighted criteria to establish a prioritized list of I.T. investments in line with Business priorities.

BEAM worked well in determining priorities; however, in today’s economy long horizon projects such as infrastructure decisions create a problem.  Many organizations are unwilling to have projects that have 18 month horizons.  Today the name of the game is short cycle and agile.  This strategy is useful in limited technical risk, but there is a tradeoff it also restricts the potential upside.

What is needed a means to merge the benefits of large projects with the flexibility or short cycle and agile.  This is where options theory shines as a method.   The feature behind Real Options (options theory) is the dividing a project or investment into a sequence of investment decisions that are made after over the course of a project.  These decisions are whether to invest another segment of the total investment.  So at each investment point or option of the project, if partitioned correctly, the decision marker is faced with determining whether the next investment is of value and alignment with current conditions.  The previous point is evaluated as to whether it reached its immediate goal, nothing more.  Likewise the next investment decision or option is only evaluated in context to what it provides.  This decision is made as to whether to invest for what value the option brings or not.  A large project becomes a series of continuation decisions over time rather than the big bang investment approach.

Bayesian decision models allow one to yield a decision based upon decision criteria factors weighted as each has different relative importance in a decision.  Applying this method –similar to BEAM—enables a more effective decision.

Quality Function Deployment aids in defining the features needed to fulfill needs.  This technique can be adapted in the design chain I’ve previously discussed in this blog.         

Translating Business to Enterprise Architecture: Case Study #1 & 2 establishment


The past week been engaged in two projects; developing a business plan for a start-up nonprofit and reviewing information technology strategy for a large existing non-profit that is trying to transform themselves.   Both projects have similar attributes and as I survey other organizations, it seems to be a common malady:  misalignment between Business and Information Technology.

In the case of the start-up, it’s more a case of designing the business to enable the technology that provides the service for its clients.  In the case of the existing nonprofit, the I.T. organization has an objective to assist the business in revitalizing itself by making itself more relevant through innovation.  A quick review of the I.T. organization’s strategy and activity indicates a strong misalignment with the current business strategy


The Startup is composed of a group of technically brilliant people all focused upon their individual technical expertise.  The issue becomes how to integrate the individual work efforts of each, build and enabling infrastructure that would support the nonprofit’s mission.  However, design of organizations are still an evolving multi-disciplinary activity that continues to present challenges as new disciplines need to be integrated into the design.  Followed by the challenge of how-to align technology to support the workflow that the organization believes gives it a competitive advantage yields a wicked problem.

This is yielding a business plan unlike the typical plans most enterprises assemble that cover the financial aspects and minimal organizational structures.  The goal of this business plan is not primarily obtaining finance or defining organizational hierarchy.  Its objective is to define a roadmap for the enterprise’s initial construction, operation and evolution.  As such more attention to system dynamics and relationships are its key features which will yield a series of states that are used for financial projections using options theory concepts to guide its evolution.   Next week the first draft will be distributed to the team for comments.       

Existing Nonprofit

Recently the I.T. organization had engaged a management consulting firm to assist.  The result of several weeks of engagement was a recommendation to rationalize the application portfolio.  While this will make the I.T. organization more cost effective, it does not necessarily support the business objective.  It brings to mind the old air travel joke:  “Pilot gets on the P.A. to tell the passengers good news and bad news.  The bad news; we’re lost, the good news we’re making excellent time”.  This I.T. organization, like so many others has focused on the technology acquisition and deployment to the exclusion of other objectives.  The rational was that they were creating capabilities for the business.   Unfortunately the business often is unable to exploit these capabilities because they require business people to be technologists or technologists to be business people –a rare skill and behavior mix in most corporations.

During my initial discussions with the I.T. group representatives, the sense that the rationalization strategy while providing local success for the group would not yield organizational success was confirmed.  This left them with a choice; focus on their own success or raise the issue and investigate on how to realign to help the business be successful or merge both objectives.  The problem with the latter two alternatives is that most I.T. organizations have never developed the competency to do such effectively.   With tightening budgets and new technologies, it’s usually all an I.T. organization can do to develop minimal competence in deployment and operation of technology, so developing a practice for alignment with business gets short attention if any.  This was all our hour discussion could achieve; however, it’s not the end of the activity we’ve schedule another meeting this coming week to discuss using the alignment methods I’ve been developing. 

Translating Business to Enterprise Architecture: Methodology Activity #3

Once a capability has been defined adequately, mapping to the components that enable it are possible.  These components are part of the resource classes originally envisioned in the conceptual model for Active Directory:

  • Hardware
  • Software
  • Human
  • Intellectual Capital
  • Financial
  • Temporal

Within these class structures further specification is accomplished based upon performance requirements and constraints.   A suite of tools were envisioned to exploit the active directory conceptual model providing status, history and planning functions.

The CIO Workbench was envisioned as an application to act as an Enterprise Architecture Repository and Planning Tool using an Active Directory database that fulfilled both I.T. and Enterprise Configuration Management Data Base Functions.

As technology has evolved today several technology functions have been developed.  The raw CMDB capability System Center suite can provide, project server has matured enough to manage project portfolios, etc.  The SharePoint 2010 with BCS appears to be able to fulfill the integration layer that connects these top applications. 

What was not address in the model above was the ability for customers to order and track fulfillment of service requests.  However, the ITIL model previously described in this blog could integrate seamlessly in this model.

The component model above was used as a planning tool to assist in creating enterprise architectures.  It becomes difficult at times to keep track of not only components in an architecture, but the levels of abstractions used also (. e.g., a Reference Model that is used as guide for an industry architecture reference model that is used to create an architecture for a specific enterprise which is further used as a reference for developing roadmaps and designs.)  This MS Access DB proved invaluable during the past years as I worked through these issues.