Tag Archives: process

There is no ā€œIā€ in IT: Oh wait yes there is.

The Dynamic Enterprise
I’m in the airport in Victoria on my way back from giving a talk sponsored by the Office of the CIO in the Government of British Columbia entitled “Enterprise-Scale Business Transformation with SOA and BPM”. Increasingly, I’m seeing efforts around large-scale Business Transformation involving the dynamic system of Business and IT.

In my talk, I asked the following question:
How do you achieve “Business Transformation” in a system that:

* Is exceedingly interdependent (or in the words of the CIO here, “tangled”)
* Responds unpredictably and dynamically to change
* Is complex enough that no single human is capable of understanding it all

In short, a system that exhibits dynamic complexity as well as high-order entropy. I have an elegant solution for this problem, but this blog entry is too short to contain it.

One Continuous Mistake
I’ve seen lately many methodologies that depend on “objective data” and measurement to align organization. Don’t get me wrong, measuring the business value of any activity is a way to align activity in a paradigm of continuous improvement. I’ve long been an admirer of Toyota Kaizen, whose principles of long-term employment, respect for the individual, empowerment and “Moving Forward” (continuous improvement) are based on a balanced and “lean” adaptation philosophy that evolves dynamically with the business environment. Not only has this facilitated the transformation of Toyota from a car maker to a hybrid car maker, but it powered their transformation from a maker of mechanical looms to a carmaker after World War II.

The granularity of the improvement cycle is a key success factor in using continuous improvement as a paradigm for business transformation. This is because a short cycle reduces the risk expose to certainties that “simply aren’t so”. @bmichelson @mtdonahue tweeted it very well by saying:

Walking on water and developing software from a specification are easy if both are frozen – Edward V Berard

What is of higher value in transformation of dynamic systems is not how you succeed, but how you fail. The ability to fail continuously and improve continuously is the secret to transformation. This requires the organization to firstly overcome fear of being “locked in” to static business processes and governance policies. Unlike the old infrastructure, the new infrastructure of Business Transformation is based on continuous improvement on short cycles and thus empowers active participation and collaboration in the shaping of optimal process. As Toyota knows, nobody knows more about process optimization than those who execute the process.

Mechanisms need to be in place for lowering the cost of failure. Short cycle times address this (borrowing from Agile), but also things like Cloud Computing’s Elastic payment model dramatically reduce the cost of failure. The era of huge IT failures should be replaced by the era of distributed intelligent transformation. Thousands of microscopic iterations of process improvement managed within a frame of trust and coordination.

An airplane is continuously off course, but also continuously reorients towards its best sense of where it’s going. As such it is capable of optimizing itself both locally (to avoid weather features and air traffic) and globally (to reduce fuel consumption and travel time). This dynamic interplay of local and global optimization is in the sweet spot for the transformational agenda.

There is no “I” in IT…oh wait yes there is.
I’ve had the great pleasure to read @davegray and his insightful post about a general theory of Information Relativity

http://communicationnation.blogspot.com/2009/06/toward-theory-of-information-relativity.html

The lovely insight here is the fundamental lack of separation between information and intention. I keep seeing transformation methodologies that depend of “objective information” to align organization, but this insight helps us to understand that information (the “difference that makes a difference”) is different from data and that the transformational power of information is inextricably intertwined with principles of presenter bias, observer bias and other key factors.


A nice commentary by toothpastefordinner.com

Nowhere is this more evident in the emergent behavior of “KPI Gaming” that manifests in organizations who have successfully implemented organizational alignment through continuous measurement of Key Performance Indicators, and have tied those KPIs to individual and organizational incentives, job descriptions and roles and organizational structure. I spoke with a CIO in Australia who bragged about how dramatically he improved project delivery time to get a fat quarterly bonus, but received a wink and a “no comment” when I pressed him on whether he rescoped any projects in order to get there. Obviously if you cut one project into 10 you can deliver projects “ten times faster”.

Mediation
This connects with the idea that “direct observation” of reality is rare and almost always mediated through our past experience and the filter of social expectation, culture and near-instantaneous mental reinterpretation. Mediation is a fundamental pattern that underlies scale in organization, as it provides a way to enforce policies, culture, route information and detect patterns. Routing information means that the organization gains the ability to amplify inspiration and best practices, while policy enables organization to enforce best practice and define itself. Of course the “mediation” pattern in Service Oriented Architecture typically involves placing a piece of hardware and/or software in the path of message flow, but there are technical architectures that perform mediation functions embedded in the endpoints.

For humans, embedding organizational culture, policy, pattern detection and information routing in the endpoint means fostering a culture that understands deeply when to escalate issues, when to share information, where to share information and when to report, stop or perpetuate behaviors. This internalization of behavioral patterns, habits and culture allows organization to achieve what Peter Drucker refers to as the goal of organization: “To enable ordinary people to do extraordinary things.”

Federation
Lorraine Lawson wrote in her blog today:
“Honestly, I’d rather write about anything besides governance, particularly SOA governance.”

http://www.itbusinessedge.com/cm/blogs/lawson/a-fresh-look-at-soa-governance/?cs=37629

This post explores the concept of Federation, the balance of regional and central authority as the differentiation between Governance and Management. Ultimately this brings me to Daryl Plummer’s folk definition of Federation which is:

“What do I have to give up in order to be a part of something bigger”.

Linking that with Drucker’s “organization enables ordinary people to do extraordinary things”, one is led to the hope that scale does not equate to life-sapping and stultifying constraint and that the autonomy that one yields to belonging is amply compensated by the scale and longevity (legacy in the positive sense of the word) of Enterprise. Although both Dilbert and “The Office” suggest that the sacrifice is your life in exchange for 20 pieces of silver, we must envision a world where great problems can be addressed at great scale.

Cycle time for continuous improvement empowers the individual to make changes in their local environment and thus experience empowerment and ownership. It’s only the rigidity of policy and process that leads to the snuffing of the individual life-force in the Enterprise.

Meditation
Or perhaps Mother Teresa is right and we cant do any great things, we can only do small things with great love.

Posted in Cloud | Tagged , , , , , , | Comments Off

Software AG signs intent agreement to acquire IDS Scheer

Creating a new one billion Euro superpower, Software AG agrees to acquire IDS Scheer, makers of the popular ARIS suite of Business Process and Business Analysis tools.

IDS Scheer represents 390M Euro of annual revenue. Combined this will result in about 1.1B Euro

After the acquisition of webMethods for $546M in April of 2007, many have speculated on the next steps in the growth aspirations of Software AG CEO Karl-Heinz Streibich–who is currently executing his aggressive 10 year plan to transform the company into a one billion Euro software superpower.

Well, that day has arrived.

Today, Mr. Streibich signed an agreement to acquire IDS Scheer, a global leader in Business Process Management (BPM) through the ARIS product family.

Posted in Cloud, Enterprise | Tagged , , , , , , , , | Comments Off

ESB Hate Storm

Lots of hate for the ESB lately.

Everything from Joe McKendrick’s E-s-Busted to Dave Linthicum’s ESB Hurting SOA, we are in the midst of a full-fledged backlash.

I’m certainly sympathetic to these views. The SOA “patient” is already pretty sick. Years of Tribal IT battles, “quick fix” technology solutions that dont interoperate and create more hassles than they fix, project funded IT driven by inconsistent objectives and just plain years of abuse. This after years of “waxy IT buildup” leaving the communications “arteries” of the company rigid and atherosclerotic. Business units are demanding solutions to Business Process problems and quick fixes that existing IT infrastructure can’t support.

Any “expensive cures” for this patient steals valuable money from proven technologies that might have a chance to save the patient. So if some vendors have exploited the pain of this sick patient, I can see why there’s so much anger in the blogosphere for this approach.

The big problem with ESB isnt that it’s of no use. as Lori MacVittie pointed out, ESB exists for good reasons.

The big lie:

The problem is that ESB by itself was sold as a “magic cure” for:

1) Silos, and

2) BPM (Business Process Management)

So along comes this “doctor” called Enterprise Service Bus. All you have to do is take the magic ESB treatment and years of architectural degeneration will be cured… right? Wrong! And the backlash against the ESB “quack doctor” begins.

The “Magic Cure for Silos” Enterprise Architects Rejoice!

Why are people so angry about this? Well, first of all, the ESB “doctor” is guilty of some amount of malpractice. The word “Enterprise” as applied to Enterprise Service Bus is really as descriptive as adding the word “Enterprise” to any piece of software that isnt Enterprise just to make it sound more serious. See, the problem is that this “Bus” wont take you downtown. It wont take you out to the suburbs. You have to change busses 10 times just to go down the street! Proponents of the ESB originally sold the “bus” as a single conduit that ran all the way across your enterprise. Frankly, this just never happened. Getting business units to “standardize” on a single vendor for ESB just hasnt been realistic. Why is this? Because every vendor has an “ESB” and some vendors have 3 or more ESBs (!) So you have an ESB slabbed on top of your Enterprise Apps from Oracle or SAP. You have an ESB from your app server vendor. You have ESBs from your integration vendor. So you end up with a half dozen different brands of ESB all over the place. So people are angry because the “Enterprise” in ESB never happened. This basically means that business unit silos are unaffected by ESB for the most part. All sales teams look for the “Enterprise License” for the products, so why not try to sell your product as a solution for an “Enterprise-wide problem”.

The “Magic Cure for BPM” Business analysts Rejoice!

The second expectation that really wigged people out was the concept of Business Processes orchestrated on top of an ESB. People had this great concept that you could take an ESB product to a business person and some standards based orchestration language like BPEL. BPEL was oversold, I think it must have been the “Business Process” in “Business Process Execution Language” that fooled people. Setting the expectation than an ESB by itself can solve the BPM problem is just naive. If you peel back the onion and look at “orchestration” flows within the ESB, you are looking at integration-logic, not the kind of logic that business people use to solve business problems.

So what’s the reality here? Reality is that you need to accept the fact that, while useful, the ESB was never designed to solve either of those problems. If you were conviced those problems would dissappear when you bought your ESB, sorry guy, you should have read the fine print. ESBs are actually pretty handy for solving integration problems. Should we throw out our ESB? No–just because an ESB is a poor environment inside of which to do BPM and a poor environment to eliminate Enterprise Silos, it happens to be a good environment within which to implement “Business Services”. Don’t think of an ESB as the thing ABOVE the services playing any kind of architectural role: think of the ESB as another kind of app server, and therefore a place inside of which you create and implement a service. Is BPEL a reasonable choice for implementing a service? It’s a little functionally limited, but sure, you could do it. So if you put the ESB in its proper place BELOW the business service interface, you can be made happy again. Leave the Enterprise Architecture and BPM to the other systems please.

So how do we go forward from here? Well, first of all give up on solving Enterprise Silo problems by either forcing a single brand of ESB across all silos or trying to program BPM in your ESB. There is no magic cure.

The (non magical) Solution

If you want to solve the problems of Enterprise Silos, you need a way to federate policy and enforce it across silos. This is what SOA Governance solutions ought to do. Get a SOA Governance solution. Is this enough? No! You also need Enterprise Architecture competency. You need a SOA Competency Center. You need to actually do the work.

If you want to solve the problem of BPM, get a BPMS. Will that please the business by itself? No! You also need to align processes with IT capabilities (services anyone?). You need to ensure that process models can be monitored with a Business Activity Monitoring (BAM) solution and you need to make adjustments (process optimization) over time. You need to do the work.

Sorry, like heart disease, you may need to make lifestyle changes. The shiny ESB you bought unfortunately wont get you all the way there. No wonder you’re mad.

My 2 cents,

Miko

Posted in Enterprise | Tagged , , , , , , , , , , , , | Comments Off