Dealing with complexity and uncertainty

I found some time to look at IBM’s last CEO Study which is named “Capitalizing on Complexity“. The main focus of the study is the increasing complexity and how to CEO’s are dealing with it. They categorized some of them as “Standouts”:

Today’s complexity is only expected to rise, and more than half of CEOs doubt their ability to manage it. Seventy-nine percent of CEOs anticipate even greater complexity ahead. However, one set of organizations — we call them “Standouts” — has turned increased complexity into financial advantage over the past five years.

Big differences between the Standouts and the others are:

  • Decision style: (54% difference between Standouts and others) “… quick decisions even when facing uncertainty.”
  • Simplify operations: (30% difference between Standouts and others) “… the need to simplify their operating
    strategies in order to better manage complexity.”
  • Business model innovation: (81% difference between Standouts and others) Types of business model innovation considered:
    • Enterprise model: Specializing and reconfiguring the business to deliver greater value by rethinking what is done in-house and through collaboration.
    • Industry model: Redefining an existing industry, moving into a new industry, or creating an entirely new one.
    • Revenue model: Changing how revenue is generated through new value propositions and new pricing models.

My conclusion is very simple, who’s dealing with increasing complexity and uncertainty in a better way can innovate more, this is the key for success.

Service Reuse

June 3, 2010 2 comments

Reuse is a topic which confuses a lot of people. Main reason for confusion is inability to understand the difference between component-based and service-oriented architectures. These have fundamentally different ways of reuse.

In component-based architecture, the idea is writing components with generic interfaces which can be used in different scenarios. So instead of implementing functions over and over, create a generic/abstract interface and reuse the function in different places. This works in different levels such as simple libraries (log4j, log4net, spring, etc), it works in large frameworks (drools, jpmn, workflow foundation, wcf, lucene, etc.) and also in infrastructure level (database servers, distributed caches etc). The idea is all same: generic stable interface, high configurability. Although this approach works very well with infrastructural components (doesn’t deliver business value directly), unfortunately, experience of the industry shows that it doesn’t work well with implementation of business processes (usually called as “business logic” in the language of this architecture style).

In service oriented architecture, reuse has a completely different meaning. Reuse of services is about existing consumers using newer version of the service. Reuse of services is “forwards” (existing consumers using new service versions) not “backwards” (new consumers using existing services). It’s not about how to implement generic services which doesn’t need to change for new consumers, it’s about how to implement services which can be extended without disturbing (upgrading) existing consumers. Therefore service compatibility and contract versioning are key concepts in service oriented architecture.

A weak understanding of services ends up with, for example, efforts to define generic service contracts. Because it’s practically not possible to know the unknown these efforts are just wasted. Usually this becomes guess-work, future-predicting. David Chappell says “Creating services that can be reused requires predicting the future…” and concludes that SOA doesn’t work. It’s very clear that he doesn’t understand the concepts of service-orientation. Similarly when Juval Lowy is excited about the capabilities of WCF and advertises the concepts “every object as a service”, same mindset presents itself. It’s not difficult to guess why WCF still doesn’t have contract-first web service development.

I noticed an InfoQ presentation “Expressing Service Capabilities Uniformly” which explains reusability as “multiple services implements same contract”. Funny that change of service contract is stated as a problem, and in the “cons” list you can find the difficulty of  change management. Of course, he doesn’t mention a word about versioning or compatibility. With his architecture style business process is reduced to “moving data from service to service” and REST is the savior. Same story over and over again…

Long story short, there are lot’s of people around who doesn’t understand service-orientation but claim it doesn’t work. Reuse is just one example. More to come…

The Open Enterprise Manifesto

BetterMeans, a company with obviously motivated individuals came up with a very nice idea of changing the corporate model. In their “Open Enterprise Manifesto” they summarize the problems of current corporate model and point out to a need of a new model. The main problems of the existing corporate model are pointed out as suppressed innovation, mistrust within organization, reward model etc. Open enterprise model introduces following concepts to the corporate model

  • Values-Centered instead of goal oriented
  • Democracy instead of top-down management
  • Currency based compensation

The problems starts at this point. Instead of analysing the current system holistically and finding out the sources of the problems, these problems are assumed to be the core problems and solution is based on them. Mistake is making this assumption. Corporate model is not there because some people had good ideas. It’s based on capitalist economic system and its values. We can historically state that current corporate model is not the most effective one, it has it’s on evolution. The question to the open enterprise is this: are you trying to evolve the current corporate model or trying to change current economic system and how it works with a paradigm shift?

If manifesto is trying to make a revolutionary change (my feeling is this is the goal), then the scope must be a lot bigger than corporate model. There’s nothing to discuss about why open enterprise model is good or bad. This is not the correct scope. It’s very naïve to think one can apply positive concepts like open source development, web-based services, democracy, being environment friendly etc. and it’ll fix all the problems. This is called “ready-fire-aim syndrome“. Zeitgeist movement is also trying to define the future similarly maybe with a better scope but also failing to identify the root causes of the problems such as “right of possession”.

If the idea is more local, the goal is only trying to improve the corporate model without assuming changes of the economical model, values of the current economical model is completely forgotten. Strength of capitalism is highly under estimated.

Microsoft and Enterprise Architecture

May 11, 2010 1 comment

Mike Walker answers the question very clearly in his post:

– Does Microsoft have an EA framework, methodology or a EA product?

– No.

He explains the “Enterprise Architecture Toolkit (EATK)” is not a framework but just one tool in the EA Toolbox. Here’s some disappointing bullets I noted from the alignment between TOGAF and EATK:

3. Create Architecture Models

There are a variety of activities have to occur to create architecture models.
1. System Architecture Document – First you need a place to describe those modes. The EATK uses the System Architecture document for this task.
2. Visio – Most architects and developers use Visio to model their architectures. The EATK has linked valuable information from the AMR so that the shapes in the model link to real assets and patterns.
3. AMR Pattern References – The AMR provides the facility for storing assets and building blocks that an organization has standardized upon.

B. Business Architecture

Supports the document management and workflow aspects however there is limited automation to these tasks.

It’s also very unfortunate that Microsoft sees enterprise architecture as an IT practice that encompass all of the various IT aspects and processes. Tom Graves explains enterprise is bigger than the organization, let alone IT, and enterprise architecture cannot be it practice. Gartner also identifies this as one of the pitfalls of enterprise architecture.

I wish we could see Microsoft more business oriented rather than technology oriented. Unfortunately this became a pattern for them despite community feedback (here on oslo, here on workflow foundation, …)

Simple Events vs. Complex Events

A Conceptual Model for Event Processing Systems” article from IBM discusses how event processing can be used to realize EDA. Article gives a good overview of event processing and defines a conceptual model for it. The goal of the conceptual model is

to form the basis for implementations of event processing systems and event-driven applications, and to provide a common framework for specifying, comparing and contrasting event processing solution architectures and implementations.

Article provides a basis for implementations of event processing systems but it definitely doesn’t provide any framework for specifying event processing architectures. This is not possible if event producing concept is reduced to Producer – Processing – Consumer relations. If the scope is not the event processing but the architectures which makes use of complex event processing, we should talk about business processes and business entity lifecycles, not producers and consumers. In this scope, the definitions for simple/complex events provided in the article will not be enough neither.

  • Simple events are those which occurs in business processes usually because of a transition in the lifecycle of a business entity. Some of these events are interesting even for other business processes and they’ll be published as notifications.
  • Complex events, however, are the outputs of complex event processing. They’re created by processing a stream of events and applying rules.

There’s a section in the article called “Business Event Processing”. I don’t know how it made into this article. Are there also “Technical Event Processing” which is most likely not interesting for business, maybe also doesn’t add business value? This section shows me very clearly that the publishers of the article were not able to see CEP in a higher scope. They’re in the level of producers and consumers, the level of implementing an event processing system, not using it.

Categories: Enterprise Integration Tags: ,

Business Entity Definition Language from IBM

April 27, 2010 2 comments

Last week IBM published the first part of a Data4BPM series:

Part 1 of this series introduces the concept of business entities as a means of representing the business view of data. It proposes two new standards, the Business Entity Definition Language (BEDL) and BPEL4Data for the holistic design and execution of process with Business Entities.

This is definitely a good move towards embracing the importance of data model in business processes. I see this in the direction of connecting different models with the efforts from Ksenia Wahler in her paper “LinkA framework for integrated process and object life cycle modeling” and Bruce Silver in his articles “Integrating Process and Rules Part 1Part 2“.

As mentioned in the paper, instead of “process-first” or “data-first” approach, a “holistic approach will prove to be most effective. However, I don’t agree that holistic means process plus data. For me holistic would as well include business rules, motivation, etc. That would be modeling all columns of Zachman framework (what, where, how, …) For example “Discovering Business Entities” section is very weak, doesn’t tell one work about business rules. You can also see that state transition rules are fit into a single attribute inside access policies. This clearly tells me, there’s a lot of space for improvement in business rules area.

What I like very much in the paper is the concept of four components of Business Entity types:

  • Lifecycle
  • Information
  • Access Policies
  • Notifications

CRUDE style in access policies (create, read, update, delete, execute state transition) somehow matches REST style which could be applied in this context. Although REST is not an approach I would take for implementing services, data services as such could be a candidate.

The link with BPEL is another point of criticism. JJ made some comments about that in his blog:

Thinking that a “Business Process Whatever Language” needs extensions to deal with Human tasks or Process Data is not just comical, it is ludicrous […]