While pondering that, the idea of using a single instance of ITIL/CoBIt across multiple provider models (i.e., ITIL Provider Types I – III) seems doable if one takes the same mindset as OS Developers have had for years: Layers of Abstraction and delayed binding:  Since the IT Governance and management functions do not require the absolute details and seven layers of precision, it is feasible.  At the highest level of governance and management I would challenge anyone to see the difference between in-house IT and Outsourcing.  The differences only become apparent when you’re at the 1st and 2nd levels of operations.  While legal and financial details are different between in-house and Outsourcing the control objectives and processes are the same, just the R&Rs and accountabilities change and are adapted to the legal structures accountable to perform.  The Service Order Management, Service Portfolio and Catalog project I’d worked on last year and blogged about prior has convinced me of that fact.

I.T. is a business within a business, but has not been managed that way.  Adopting Service Management enables switching to that perspective.  That switch of perspective permits a CIO to consider other aspects of I.T. that have been not given a due consideration.  The surround around the technical aspects of an offering in business ( (Slywotzky, 1995) (Marks, 1998) has influence on success as much and in many cases more than the technical features.

Designing the attributes of the surround is something many businesses do by default and I.T. organizations are not even aware of but could benefit greatly by addressing.

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.

I look at the General System Theory references, the older engineering references, and systems engineering materials of the past few decades and see all the same things.  But the question becomes, why haven’t we applied it all?  Maybe we’ve gotten so caught up in making a living, acquiring status that we forgot to have a life.  Those that I’ve talked to that have a full schedule of activities seem to be in no better shape; they acquire experiences much the same way others acquire material possessions.  They can list dozens of activities they and their family have done, but it sounds more like a checklist off a to do list and an actual meaningful event.  

A little off my typical technology blog, but still relevant.  Have we spend so much time doing our checklists that we have forgotten what we’re doing them for?  I recently talked to a client about their operations.  The processes they use were old, inefficient and in some cases just didn’t accomplish anything.  The typical answer I got when asking why they did what they did was “We’ve always done it that way”.  It reminded me of the joke about the family roast recipe.  A great granddaughter carefully cut off the ends of the roast before placing it in a pan.  The husband asked why.  She didn’t know and called  her mother who call her mother and so on till they reach the great-grandmother who was asked why she did that.  Her reply was the roast was always too big for my roasting pan.

The question I have for us, myself included am I cutting off the ends of a roast at work or in other activties? 

The unfortunate fact about this book was that the core message was never addressed by industry; Design Decisions determine overall costs and therefore should require special attention.  Today there is much talk about Cloud, reducing costs and converting CAPX (Capital Expenses) to OPEX (Operations Expenses).  If not considered carefully, switching from an On-Premise solution to Cloud will cost an Enterprise more and not provide the benefits anticipated.

This is not to say Cloud is not a valuable strategy.  Much to the contrary.  However, to really take advantage of the elastic nature of Cloud requires planning.  Planning on how to optimize the technology, utilize the elasticity it offers and mitigate the risks.  Without investing the time and effort it becomes not an opportunity but a pay me now or pay me later situation

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.

During 1996 I was introduced to Viable Systems Models created by Stafford Beer.   I used VSM during that year to model various forms of governance models. Later these models were converted to dynamic systems models to simulate in ITHINK to determine consequences both long and short term of various alternatives.  The simulation results provided justification for picking a particular alternative.   Of more importance the various models provided a means of dialog between decision makers to explore the alternatives based upon various priorities and other potential effects.

This has yield the need to evaluate alternatives using some form of multi-variant analysis.  Bayesian analysis appears to be able to address this requirement.

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.

This is one view of a multi-dimensional concept.

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.

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.