Achieving Business Outcome With Enterprise Architecture

The Art of Enterprise Architecture – Section 13 – The use of architects

Jörgen Dahlberg — Mon, 26 Dec 2011 16:31:53 +0000

The mistake of the many

Raising a host of all employees and marching them great distances entails heavy loss on the people and a drain on the resources of the Enterprise. The daily expenditure will easily surmount that which can ever be gained. There will be commotion in the organization and the network, and men will drop down exhausted on the floors.

The wise leader and the good manager

Stakeholders may face each other for years, striving for the consensus which should be decided in a single day. This being so, to remain in ignorance of the stakeholders condition simply because one grudges the outlay of a small amount of funds, is the height of inhumanity. One who acts thus is no leader of men, no present help to the owners, no master of victory. Thus, what enables the wise leader and the good manager to act and win, and achieve things beyond the reach of ordinary men, is foreknowledge. Now this foreknowledge cannot be elicited from spirits; it cannot be obtained inductively from experience, nor by any deductive calculation. Knowledge of the stakeholders dispositions can only be obtained from other men. Hence the use of architects.

Four classes of architects

Business architects;
Enterprise architects;
Domain architects;
Solution architects;

When these four kinds of architects are all at work, none can discover the secret system. This is called “divine manipulation of the threads.” It is the leaders most precious faculty.

Having business architects means employing the services of the leaders of a business domain. Having enterprise architects, making use of managers of the stakeholders. Having domain architects, getting hold of the domain specific information and using it to further our purposes. Having solution architects, doing certain things openly for purposes of inclusion. Hence it is that which none in the whole organization are more intimate relations to be maintained than with architects. None should be more liberally rewarded. In no other business should greater security be preserved.

Employing architects

Architects cannot be usefully employed without a certain intuitive sagacity. They cannot be properly managed without benevolence and straightforwardness. Without subtle ingenuity of mind, one cannot make certain of the truth of their reports. Be subtle! be subtle! and use your architects for every kind of business. If a certain piece of insight is divulged by an architect before the time is ripe, he must be silenced together with the man to whom the secret was told.

Whether the object be to optimize a business unit, to move a product on to the market, or to execute mergers and acquisitions, it is always necessary to begin by finding out the names of the attendants, the aides-de-camp, and door-keepers and sentries of the managers in command. Our architects must be commissioned to ascertain these.

The end and aim of architecting in all its varieties is knowledge of the stakeholders businesses; and this knowledge can only be derived, in the first instance, from the domain architect. Hence it is essential that the domain architect be treated with the utmost liberality.

Hence it is only the enlightened leader and the wise manager who will use the highest intelligence of the enterprise for purposes of architecting and thereby they achieve great results. Architects are a most important element in water (emotion and intuition), because on them depends an enterprise ability to move.

—————————————————————-

You can read Section One here: section-one-strategy

You can read Section Two here: section-two-doing-architecture

You can read Section Three here: section-three-planning-the-architecture

You can read Section Four here: section-four-tactical-dispositions

You can read Section Five here: section-five-directing-energy

You can read Section Six here: section-six-strengths-and-weaknesses

You can read Section Seven here: section-seven-maneuvering

You can read Section Eight here: section-eight-variation-in-tactics

You can read Section Nine here: section-nine-on-the-march

You can read Section Ten here: section-ten-domains

You can read Section Eleven here: section-eleven-situations

You can read Section Twelve here: section-twelve-investigation-by-process

The text above is based upon the writings of Sun Tzu in the Art of War. Several translations has been read prior to writing the text above, but the most prominently used translation is the one retrieved from “http://en.wikisource.org/wiki/The_Art_of_War_(Sun)”. I consider the text above a work in progress…

The Art of Enterprise Architecture – Section 12 – The investigation by process

Jörgen Dahlberg — Mon, 26 Dec 2011 12:03:57 +0000

The six ways

There are six ways of investigating by process. The first is to go by strategic intent; the second is to follow the business models; the third is to go by information need; the fourth is to trace through application usage; the fifth is to trace through the organizations; the sixth is to benchmark to a reference model.

In order to carry out an investigation, we must have means available. The material for process investigations should always be kept in readiness. As well as the needed means there is a proper time for execution when it comes to architecture. This time is governed by the cycles of the business as operated by the enterprise.

Five possible developments

In investigating by process, one should be prepared to meet five possible developments:

When people disagree as to what the process is, respond at once with an investigation from without (business model).
If there is a burning issue, but the stakeholders remain quiet, bide your time and do not investigate.
When the force of the politics has reached its height, follow it up with an investigation, if that is practicable; if not, stay where you are.
If it is possible to make an investigation from without, do not wait for permit to investigate from within, but start your investigation by strategic intent and business model at a favorable moment.
When you start an investigation, stay on the logical side. Do not drift into the emotional side.

In every enterprise, the five developments connected with process must be known, the movements of the markets watched, and a eye kept on the cycles of business. Hence those who use process as an aid to the investigation show intelligence and those who use experience as an aid to the investigation gain an accession of strength. As we have learned by means of experience, a problem may be interpreted, but not understood in all of its details.

The true fate

An effort that starts in the response of true vision lasts long, but a reaction to things already happened soon falls.

Unhappy is the fate of one who tries to fulfill his mission and succeed in business without cultivating the spirit of enterprise; for the result is waste of time and general stagnation. Hence the saying: The enlightened leader lays his plans well ahead; the good manager cultivates his resources. Considering the saying you should take no action unless you see an advantage; use not your men unless there is something to be gained; investigate not unless the need is great.

No leader should put architects into the enterprise merely to gratify his own spleen; no manager should launch an investigation simply out of pique.

An enterprise that has once been destroyed can never come again into being; nor can time lost ever be gained a new. Hence the enlightened leader is heedful, and the good manager full of caution. This is the way to keep a enterprise successful and a capability intact.

—————————————————————-

You can read Section One here: section-one-strategy

You can read Section Two here: section-two-doing-architecture

You can read Section Three here: section-three-planning-the-architecture

You can read Section Four here: section-four-tactical-dispositions

You can read Section Five here: section-five-directing-energy

You can read Section Six here: section-six-strengths-and-weaknesses

You can read Section Seven here: section-seven-maneuvering

You can read Section Eight here: section-eight-variation-in-tactics

You can read Section Nine here: section-nine-on-the-march

You can read Section Ten here: section-ten-domains

You can read Section Eleven here: section-eleven-situations

The Art of Enterprise Architecture – Section 11 – Situations

Jörgen Dahlberg — Mon, 26 Dec 2011 08:33:10 +0000

The art of architecture recognizes nine varieties of situations:

When an architect is fighting within his own profession, it is a dispersive situation.
When an architect has investigated a problem, but to no great depth, it is a facile situation.
When an architect find no alignment on the nature of things, it is a contentious situation.
When an architect leave freedom of choice, it is an open situation.
When an architect is faced with shared resources, is is an intersecting situation.
When an architect is faced with entrenched allegiances, federated structures, politics or secrecy, it is a difficult situation.
When an architect has wested his word, it is a hemmed in situation.
When an architect is overrun by solutions, it is a desperate situation.
When an architect has established an enterprise architecture capability, blueprints and plans, it is a serious situation.

To give advice on how to address each of these nine situations is within the experience of the guide. Acceptance of the advice lie at the heart of the matter and can only be given by the receiver. Such then is the advice on the nine situations:

When in a dispersive situation, therefore, fight not. In a facile situation, halt not. In a contentious situation, attack not. In an open situation, do not try to block choice. In an intersecting situation, seek consensus. In a serious situation, reap the benefits. In a difficult situation, keep focused on the mission. In a hemmed-in situation, resort to stratagem. In a desperate situation, fight.

The different measures suited to the nine varieties of situations; the expediency of aggressive or defensive tactics; and the fundamental laws of human nature: these are things that must most certainly be studied.

Therefore, in a dispersive situation, I would inspire my men with unity of purpose. In a facile situation, I would see that there is close connection between all parts of my team. In a contentious situation, I would make effort to bring those misaligned to the table. In an open situation, I would keep a vigilant eye on the solutions. In an intersecting situation, I would consolidate my alliances. In a serious situation, I would try to ensure a continuous stream of missions. In a difficult situation, I would keep pushing on along the path taken. In a hemmed-in situation, I would burn my ships and set sail. In a desperate situation, I would proclaim to my team the hopelessness of creating any architecture.

We cannot enter into alliance with sponsors until we are acquainted with their designs. We are not fit to lead an team on a mission unless we are familiar with the problem and situation. We shall be unable to turn obvious advantages to account unless we make use of local guides.

The following are the principles to be observed when establishing an architecture capability:

The further you establish the way of working with architecture, the greater will be the solidarity of your peers, and thus the opposition will not prevail against you.
Pick the low hanging fruits in order to supply your mission with provable arguments of its superiority.
Carefully study the well-being of your men, and do not overtax them. Concentrate your energy and hoard your strength. Keep your team continually on the move, and devise unfathomable plans.
Throw your architects into positions whence there is no escape, and they will prefer failure to flight. If they will face failure, there is nothing they may not achieve. Leaders and men alike will put forth their uttermost strength.
Architects when in desperate straits lose the sense of fear. If there is no place of refuge, they will stand firm. If they are in hostile units, they will show a stubborn front. If there is no help for it, they will persist.
Thus, without waiting to be marshaled, the architects will be constantly on the lookout; without waiting to be asked, they will do your will; without restrictions, they will be faithful; without giving orders, they can be trusted.
Prohibit politics, and do away with unfounded doubts. Then, until the mission is completed, no calamity need be feared.
The principle on which to manage an architecture capability is to set up one standard of excellence which all must reach.
How to make the best of both analytical thinkers and those drawn to facilitation – that is a question involving the proper use of situations.
Thus the skillful chief architect conducts his team just as though he were leading a single man, willy-nilly, by the hand.
It is the way of a chief architect to be quiet and thus ensure secrecy; upright and just, and thus maintain order.

—————————————————————-

You can read Section One here: section-one-strategy

You can read Section Two here: section-two-doing-architecture

You can read Section Three here: section-three-planning-the-architecture

You can read Section Four here: section-four-tactical-dispositions

You can read Section Five here: section-five-directing-energy

You can read Section Six here: section-six-strengths-and-weaknesses

You can read Section Seven here: section-seven-maneuvering

You can read Section Eight here: section-eight-variation-in-tactics

You can read Section Nine here: section-nine-on-the-march

You can read Section Ten here: section-ten-domains

The usual case?

Jörgen Dahlberg — Fri, 02 Dec 2011 06:44:02 +0000

Going back to Bohms discussions on problem versus paradox, could it be that the same apply to the diciplines of architecture versus strategic planning? Page 72-73

Could à paradox be in existens that all concerned (business and IT) seem to understand their common Enterprise and mutual dependence, which imply the need to be open to each other, while nevertheless, each person feels that his own particular “needs” are being ignored or rejected by the other, so that he is “hurt” and rests with a “defense mechanism” preventing him from really listening to what the other person means to say. Pages 74.

Is there a domain architecture trend in the architecture community?

Jörgen Dahlberg — Sat, 12 Nov 2011 09:04:44 +0000

I’ve observed what could be a trend in how people go about doing architecture for the enterprise. I’m not certain that this is an established trend, but I’ve asked around and apparently other people have noticed the same movement in their community. The trend would be doing domain architecture and relinquishing the effort of creating a coherent enterprise architecture. I believe that such a trend with domain architecture over enterprise architecture could be a sign that people have lost faith in the general organizations ability to convert to an agile and efficient society model that should serve all constituents. As a consultant in enterprise architecture, I get to experience these issues first handed across the industry. I think that it can be problematic if too many people think mainly to save themselves and not looking for larger solutions. Concurrent I think it’s good that especially many people within the organizations shows that they take architecture issues seriously. However failing to recognize that there are different perspectives at play simultaneously will inevitability cause a corruption of the “whole”.

This is what I talk about when I say capability

Jörgen Dahlberg — Sat, 05 Nov 2011 13:43:49 +0000

This post has been updated, and all updated text should be highlighted blue.

I was asked the question I love to get the other day, “what do you mean by capability?”. I usually try to be brief when I explain my point of view and so I was this time to. However in this post I’ve elaborated somewhat on the details of my explanation. This is not the last answer on this topic but it will give an indication to how I’m currently viewing capabilities.

My first attempt at getting some sort of definition down

Only a “whole” can contain a capability. Thus a human or an organization could be said to be able to posses capabilities to perform a certain set of activities that will ensure delivery of an anticipated value. An application, a device or any combination of products and services can not be said to be able to contain capabilities. Applications, devices and such types of things contain functions. These functions are at times marketed under the label “capabilities”, but they are functions nothing else.

Where I am now NOT including the above

I once created a 7 day training on Enterprise architecture from a holistic and practical perspective. In that course on day five or six it must have been, I challenged everyone to explore the possibility of viewing a complete business model as one capability of the business. Why may I have this view on capabilities one may ask. The business model as I’m used to describe them is a static description of how the enterprise will service the customer, as well as how it will utilize the services of other organizations. In my mind this idea of business models as capabilities fits well with the notion that only animate and social systems can be purposeful (1).

Some assumptions:

The business model is a complete architecture description in such a sense that it covers the whole that we seek to explore.
The business model represents a high level perspective of the detailed architecture.
Using the business model as a foundation we can detail things as far as we need to understand them in a solutions perspective.
When a business model needs to change there is a possibility that the underlying capability will need to change.
We can pre-produce business models and put them on the shelves.
We select the business models we would like to use.
Business functions in general is a configuration used across a set of capabilities.

Some rough definitions:

Business model = A static description of what a business must coordinate to meet a coherent set of value propositions.
Value proposition = The perceived value of the products and services offered as viewed from the customers perspective.
Customer segments = The way we segment the customers and non-customers in the market as targets for the offered value propositions.
Customer relations = The link we maintain between the customer segments and the value proposition.
Processes = The activities we need to perform to be able to service the value propositions.
Value network = The partners and suppliers we work together with in our processes.
Resources = The things and competences we use in our processes.
Costs = The collection of costs accrued by executing the business model.
Revenue = The collection of revenues generated by the customer segments as they consume the value propositions.

What is a complete business model?

One may ask what do I mean by a complete business model, and why is that different from any one business model? When I use the business model framework I may use it on different levels within an enterprise. Using the business model framework like this means that there will be business models that are not of a directly value creating perspective, rather they are supporting the value creation/value consumption. The easy way to spot these supporting structures is to look at the customer segments. If there are only enterprise internal customer segments then this is a supporting business model. I would not consider a supporting business model a capability but rather a function that must be performed within a larger structure. I do however consider it appropriate to use the business model framework as a means to design and link these supporting functions.

Why is a supporting business model a business function and not a business capability?

A supporting business model as one could construct for human resources, finance or IT has no intent outside of the intent of the complete business. Yes you may very well have HR-, Finance- and IT-strategies but they are just relative to the business strategy. Each business function maintains its autonomy relative to the constraints set by its environment, but contributes to the production of the larger enterprise system. Each and everyone of these business functions will make use of parts of the capabilities available to the enterprise, but that does not make them a capability of their own right. As I’ve come to see it there there is a true difference between a business function and a business capability. Let me make it clear that what I describe in this section is not aimed at defining what makes up a business model or a business function, it is about using a tool designed to find business models to find candidate business functions.

The good things with this definition

If one use the definition that I’ve described above then

There will not be an abundant of capabilities floating around in the enterprise.
The very small set of capabilities is the focus of the entire enterprise.
There is no need for capabilities within capabilities.
Functions clearly hold their own right to be in the architecture.

REF:

(1) http://www.acasa.upenn.edu/4sys.htm

(2) http://en.wikipedia.org/wiki/Business_model

Classification of Intangiables and/or tangibles

Jörgen Dahlberg — Fri, 21 Oct 2011 11:16:10 +0000

In an article at The Scottish Intellectual Assets Centre http://www.ia-centre.org.uk/iam_explained/ they explained what could be used to shape a basic classification of Intellectual Assets.

Intellectual Assets

Registered

Patents
Trademarks
Design Rights
Copyright
Database Rights

Unregistered

Trade Secrets
Technical Info
Contracts
Accreditation
Show How

10 Key Success Factors for dealing with Enterprise Architecture

Jörgen Dahlberg — Fri, 21 Oct 2011 11:12:08 +0000

Secure the entire management commitment
Secure scope(s) (partition)
Customize methodologies to fit your intentions
Use tools to support implementation
Use training and coaching to secure knowledge and commitment is within specified limits.
Use metrics to monitor the effects of Enterprise Architecture
Create a set oriented fractal meta-model (yeah I know this sound weird)
Use as few languages as possible
Manage materials, methods and resource
Use experts to get on track quick and right

10 business trends for enterprise architecture in the ’10s (zdnet.com)

5 steps to awesomeness

Jörgen Dahlberg — Fri, 30 Sep 2011 05:28:48 +0000

1. Envision
From ideation through environmental analysis to concrete vision and business case
2. Enable
From business case through architecture to proposed solution
3. Engage
From solution through construction to operations
4. Enforce
From policy through coaching to culture
5. Ensure
From culture through meassures to continous improvement

Sketches on Bohms dialogue

Jörgen Dahlberg — Wed, 28 Sep 2011 20:28:37 +0000

I’ve been diving into some fascinating work by Bohm on making people understand each other. I did some pen sketches during my reading that I later transfered into a tool to visualize. Use this to unpack any meeting or use them in pow-wows it’s extremely helpful.

The basic model

Two parties joined in dialog

Achieving Business Outcome With Enterprise Architecture

The Art of Enterprise Architecture – Section 13 – The use of architects

The Art of Enterprise Architecture – Section 12 – The investigation by process

The Art of Enterprise Architecture – Section 11 – Situations

The usual case?

Is there a domain architecture trend in the architecture community?

This is what I talk about when I say capability

Classification of Intangiables and/or tangibles

10 Key Success Factors for dealing with Enterprise Architecture

Related articles

5 steps to awesomeness

Sketches on Bohms dialogue