Steve Jones reminds us that the business doesn’t care about technology – so stop harping about it and using it as an excuse for underperformance.

I totally agree that this is a key reason behind the endemic business/IT culture divide that is the root of many problems.

However this poses an obvious question – who does care about the technology?. The trick is not to over-engineer, but to engineer to just the right level to deliver business value now and into the future.

Somebody has to care about the technology (products, tools, methodologies), because otherwise you lose control and foster a legacy of technical debt which ultimately erodes business value.

I guess this is an axiom of Enterprise Architecture – that lack of governance leads to chaos and inefficiencies. Some would argue with this assertion, but I have never seen a counter-example. And of course the inverse statement is not necessarily true either.

So if the business doesn’t care about technology then who does? And if that is “nobody” then what happens?

Imagine you have a unique business offering that needs IT delivery and support. There are two approaches you can take to do this:

Bottom Up:

1. Determine your business requirements.
2. Choose an application which you think best fits those requirements.
3. Spend a lot of money customizing the application to better fit your requirements and integrating it to other systems.
4. Deploy the application.
5. Hope you support the business adequately within time and budget.

Top Down:

1. Map out the business processes to support your offering.
2. Determine the services required to support the business processes.
3. For services that already exist – do nothing.
4. For new services – build or buy applications to support those services.
5. Implement the processes.
6. Hope….(ditto).

Often “bottom up” is the default approach, even though “top down” can be more cost-effective and provide a closer fit to your business requirements. However “top down” comes with some risk, because most off-the-shelf applications are built to support “bottom up” acquisition. You might end up having to do integration anyway.

As the world moves toward service portfolio management rather than application portfolio management, vendors move towards offering services rather than applications and the “top down” approach will become more widespread and more viable. That will be a good thing, I think.

Happy New Year! Asynchronicity is busting out all over the web and my prediction is that 2010 will be the year of “events”:

• Of course Twitter has brought The concept of publish/subscribe messaging to the masses and we enjoyed their journey of discovery to the heights of scalability in 2009.
• XMPP has been embraced by the real-time web crowd, most publicly in Google Wave but also in other “back-web” contexts such as Gnip.
• Web sockets is an experimental feature of HTML 5 which enables push messages directly to web pages.
• New frameworks for event-driven programming are emerging such as EventMachine, Twisted, Node.js.
• In 2009 every major software vendor had a CEP product.

In the meantime, SOA has become so damn synchronous. But it doesn’t have to be!

One of the fundamental tennets of SOA is that reducing coupling between systems makes them more scalable, reliable and agile (easier to change). SOA goes a long way to reducing coupling by providing a contract-based, platform independent mechanism for service providers and consumers to cooperate. However I still think we can improve on current SOA practices in further reducing coupling.

Coupling still intrudes into many aspects of how SOA is practiced today:

• HTTP transports tie us to a regimen of synchronous request-reply with timeouts which creates tight couplings between provider and consumer. Even though one-way MEPs were an original feature of SOAP, message-oriented transports remain the forgotten orphan of web-services standards.
• Many SOA services are conceived, implemented and maintained as point-to-point entities…providers and consumers forced into lock-step due to inadequate versioning and lifecycle management.
• Process orchestration layers often form a bridge between service providers and consumers, which on the face of it provides some level of indirection. But in many cases orchestration provides limited value and may actually serve to increase the overall system coupling.

In many cases we can achieve the benefits of service orientation to much greater effect by exercising a little scepticism toward some of these shibboleths of the web services world and embracing a more asynchronous, event-oriented way of building processes. So this year, embrace your asynchronous side and do something to reduce your system coupling: build some pub/sub services, learn about Event Processing or Event-Driven Architecture, try one of the technologies I pointed to above.

Just as developers should embrace multiple languages to broaden their skills, so should architects embrace and be fluent in multiple architectural styles.

In a recent comment on my Architectural Characteristics posts, Andy astutely observes that I may be “shoe-horning”. By this I assume he means that I’m taking a large and rather lumpy concept and trying to squeeze it into a smaller and more uniformly shaped container while risking some distortion in the process. I’ll admit that in this respect I’m probably guilty as charged.

But I should clarify my purpose in doing this. I’m trying to cut back the various architectural styles under consideration to a simpler form where the essential characteristics can be discerned without confusion from some other non-essential characteristics. So rather than shoehorning, I’m trying to setup a strawman model which can be used as a starting point for discussion. Or maybe like a physicist I’m trying to model a very complex phenomenon using linear approximations which explain the broad outlines of the phenomenon at the risk of falling short on some of the details.

To extend this latter metaphor, I don’t think it is too much of a stretch to say that the architectural styles I’m considering could be likened to “fundamental” architectural styles and that real-world architectures could be viewed as “superpositions” of those fundamental architectures.

If we consider the simplified forms of EAI and SOA that I describe, each style falls short of representing a real world architecture, but the upside is that the EAI and SOA styles as I describe them are distinct and easily differentiated. So we have a model which provides a way of distinguishing between different styles (via the characteristics I’ve discussed) but falls short of exactly matching a “real-world” architecure.

If we look at any real-world architecture in recent years, I think we can see a superposition of EAI and SOA concepts. This probably reflects an evolutionary path between the two styles. EAI as practiced in the early noughties had already developed the idea of a normalised data model and technology independent interfaces. These were not standardized, but some of the characteristics of SOA were apparent in what was then called EAI.

Similarly, EAI was not always about data integration. There was (and is) a distinction between data integration and process integration. EAI techniques could be used to orchestrate processes across multiple systems. This is even closer to the concept of SOA which has at its core the notion of an independent process layer seperate from the service layer.

Even if we don’t superpose EAI and SOA into one solution, there are still legitimate ways in which EAI, SOA and EDA coexist within any particular architecture. We can easily imagine a solution in which a business process is orchestrated via SOA services, reference data is synchronised using EAI and overall process state is monitored using EDA techniques such as Event Processing.

So real-world solution architectures exhibit some overlap between the different architectural styles – EAI, SOA and EDA. Some of this is due to evolutionary legacies, or due to plain-old confusion between the different styles (e.g. JABOWS as really being EAI). Some of it is also due to legitimate mixing of different styles for different aspects of a solution.

I think that real-world architectures can benefit from seperating out the “essence” of each architectural style and being explicit about how those styles are being applied. Reducing architectural styles to simplified forms clarifies the stucture of a real-world architecture. Not very different from Design Patterns, really.

Dion Hinchcliffe has written a nice blog entry “pragmatic new models for enterprise architecture take shape“. This resonates well with some of the things I’ve been saying about how enterprise architecture needs to be enabling rather than blocking:

“In recent years enterprise architecture has been moving from a discipline that provides top-down, a priori technology blueprints to the business side to one that articulates key, strategic possibilities and only the most critical high-level constraints (such as security standards) and then operates as a conductor, promoter, problem solver, and evangelist across the organization through the vehicle of a cohesive community to co-develop needed solutions.”

(my emphasis added). And:

“Invariably, the best architecture I see comes naturally from self-organizing thought leaders in an organization that seek each other out and collaborate on common solutions to their problems. Rather than the us vs. them mentality of old-world enterprise architecture, there is only an us mentality. Instead of prescribed standards, designs, technologies, and tools there is real [two-way] consensus and immediate buy-in.”

And as with all Dion’s posts there is the cool graphic. I especially like the two downward facing arrows – “community leadership” and “guides”:

The article is well worth reading but I think there is a large element of wishful thinking here. It paints a good picture of how enterprise architecture should be, but I fear we are a long way from this nirvana. Much of the vision depends on a fundamental change in organizational culture. Businesses that recognise the value of an “emergent culture” will naturally have an “emergent enterprise architecture.” I don’t think it will go the other way around. Emergent enterprise architecture will not survive in or be able to change a top-down corporation.

In the long term, those companies with the right culture will support emergent enterprise architecture and thrive on IT success. Those companies that don’t will cede their IT resources to others. Those who can do IT will do it on behalf of those who can’t. Cloud anyone?