Automating a Strategy Requires an Enterprise Ontology

I gave a presentation on Strategic Planning last week to a small of group of colleagues. It went quite well in that some (if not all) of the material was new to them. Exposure to the concept that  organizational and competitive business design can be traced from business strategy through to IT enablement (automation) was delivered by yours truly. Upon further reflection post meeting, it then occurred to me that if theoretical traceability can be achieved top to bottom, is it not possible then to fully automate a strategy and measure its progress in some way?

The crux of this matter, IMHO, is being able to describe a strategy in machine readable terms that can then be acted upon. It turns out that StratML (which has been in development for quite some time) provides the means to successfully describe a strategy that a computer can consume. However to act on it in a meaningful way requires some level of interpretation or "intelligence" that understands it along with knowledge of the environment (both internal and external) in which the strategy executes. Deriving from this, the two main requisites for strategy automation are "sufficiently encoded intelligence or reasoning machines" that overly the strategy on to an ontology of the enterprise and the external environment in which it resides. As a result of having these two conditions met, strategies can be designed and tested before their actual implementation saving time and money.

I firmly believe that we are not far from this business nirvana. Efforts in ontological design and information capture, along with advances in AI, will be provide the necessary steps forward. The question is "who will get there first" and "will they benefit the most"?

Definition of Enterprise Architecture

Even though this is a Strategy Oriented Architecture blog (business designed and organized by business strategy), let us include some EA material for reference to help us set the background to give us the ability to differentiate ourselves later on..




There is no one authoritative definition of EA but I believe it could be “the practice of describing, aligning and advancing the business of an organization from all perspectives in harmony with its internal culture and external resource base”.


There are many definitions of EA, a student of EA needs to have one they feel comfortable with.

Mapping Services to Maslow's Hierarchy

For those who have heard me speak on this topic in the past, I have posted the mapping here for posterity.


I have mapped Maslow's extended Needs Hierarchy to Service Types to indicate future service offering intentions. I believe that services will evolve instep with the technology base that supports them.

 For those who understand strategic advantage in the marketplace, the evolution of services  over time to higher order service types follows the natural evolution of human civilization.

Service Orthographic

For those more interested in a mathematical approach to visualizing services, consider a pool of all services whereby a service type is an orthogonal plane to various domains with ranges of constraints. If we set the constraints to a particular value, then we could say that a service is locked down and is now a line within the service type plane as illustrated below.

I like this diagram as it clearly indicates that a service can span many domains not just the technological or application.

Contemplating Services...

Goods and Services: Is there ever a good without a service to provide it?

Interactions: Ever try to do anything without consuming or providing a service (in some form) for yourself, family, friends, employer or with respect to your government?

The Ultimate Provider: Is nature really just a BIG service provider and we are all just service consumers? 

The key point behind all of this is that any human activity in my opinion, is at its very essence, a service and its set of interactions. Even the human body contains organs and cells each providing a service to the community (body) they reside in. Perhaps only nature can provide products without services to encompass them. Products such as energy, mass, space, gravity... 

Enterprise Maturity Levels to Examine First

There are two key maturity level indicators to analyze first when attempting to establish an Enterprise Architecture program in an organization:

The first is the maturity level of the organization with respect to project and program management. If an organization is not very capable in managing projects and programs, they will similarly not be able to manage the potential change outcomes of an Enterprise Architecture program.

The second maturity level to note is the architecture design, development and capture in both the business and technology realms. If an organization does not capture its architecture for reuse or for referenceable knowledge, then the outcomes of an Enterprise Architecture program, which sometimes produces MORE abstract material then just pure architecture, will not be consumable. An organization has to have the ability to architect projects first before embarking on architecting the enterprise – similar to walking before running.