Chapter Eight is about social data APIs and pushes gnip heavily as the de facto social endpoint aggregator for programmers. The chapter mentions WebHooks as an up and coming HTTP Post event transmission project but doesn’t offer much more than a wake up call for programmers. The traditional polling has dominated web APIs and has lead to fragile points of failure. This chapter is a much needed call for sanity in the insane world of HTTP transactional polling. Unfortunately, the community seems to be so in love with the simplicity of polling that they use it for everything, even when a slightly more complicated eventing model would save them a large percentage of transactions.

The link “fragile points of failure” is worth following as it leads to a robust slashdot discussion on Twitter APIs and polling versus push for the web.

I think for a long time, the “web” as we know it has suffered from the lack of the Event/Listener paradigm. This is a pretty simple design concept that I’m going to refer to as the Observer [wikipedia.org]. Let’s say I want to know what Stephen Hawking is tweeting about and I want to know 24/7. Now if you have to make more than one call, something is wrong. That one call should be a notification to Twitter who I am, where you can contact me and what I want to keep tabs on–be it a keyword or user. So all I should ever have to do is tell Twitter I want to know everything from Stephen Hawking and everything with #stephenhawking or whatever and from that point on, it will try to submit that message to me via any number of technologies. Simple pub/sub [wikipedia.org] message queues could be implemented here to alleviate my need to continually go to Twitter and say: “Has Stephen Hawking said anything new yet? *millisecond pause* Has Stephen Hawking said anything new yet? *millisecond pause* …” ad infinitum.

And yet…

That’s not easy to do on a large scale. A persistent connection has to be in place between publisher and subscriber. Twitter would have to have a huge number of low-traffic connections open. (Hopefully only one per subscriber, not one per publisher/subscriber combination.) Then, on the server side, they’d have to have a routing system to track who’s following what, invert that information, and blast out a message to all followers whenever there was an update. This is all quite feasible, but it’s quite different from the classic HTTP model.

It’s been done before, though. Remember Push technology [wikipedia.org]? That’s what this is. PointCast sent their final news/stock push message [cnet.com] in February 2000. There’s more support for “push” in HTML5, incidentally.

Ahhh yes, I remember PointCast well. One of the early darlings of the dot-com era. This reply points at some new hope:

For messaging architectures (like, say, the internet), the pattern is usually described as “Publish/Subscribe”. All serious messaging protocols support it (XMPP, AMQP, etc.) and some are dedicated to it (PubSubHubbub). The basic problem with using it the whole way to the client is that many clients are run in environments where it is impractical to run a server which makes recieving inbound connections difficult.

There are fairly good solutions to that, mostly involving using a proxy for the client somewhere that can run a server which holds messages, and then having the client call the proxy (rather than the message sources) to get all the pending messages together.

Keep watching.

Related posts:

1. Push versus Pull
2. 56 Architecture Case Studies
3. The Year of Living Asynchronously

1. A collaborative business and IT culture that owns and manages risk rather than just outsource and lose control.
2. An Enterprise IT strategy and Architecture that provides “cohesion” so that smaller, agile projects can deliver strategic value.
3. Using (and developing in-house) development frameworks that enhance productivity by:
   • encouraging in-house standards and best practices,
   • operating at a high level of abstraction – business processes, services, events, rules
   • foster developer skills beyond “commodity” levels.

Related posts:

1. 11. Don’t Raise the Drawbridge
2. The Value of Enterprise Architecture

• 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.

Related posts:

1. The benefits of an ESB
2. Ian Robinson on Coupling
3. What is an ESB and why do I need one?

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.

Related posts:

1. Characterising Architectural Styles II – State
2. The Year of Living Asynchronously

(I could comment further, but it speaks for itself).

Go visit and find out.

No related posts.

There are three aspects of state that I want to consider:

• Management - how state change is initiated or managed through a business process.
• Monitoring - how state is monitored or accessed or derived during the execution of a business process.
• Consistency - how state is made consistent across different systems involved in a business process.

A summary of the state characteristics of the different architectural styles is listed in the following table along with the other characteristics discussed in my last post.

In EAI, state is managed within one application and then synchronised to other applications, usually after the business process has completed. This means that in some cases state may be inconsistent across the organisation or its systems. That may or may not be a problem (see ‘Eventually Consistent‘) but is a common side effect when a business process is executed within one system rather than across systems in an independent process layer. During the execution of an EAI process, there is often no monitoring of the state. I.e. the process may simply replicate data changes to other systems without explicily tracking state. A limited form of state monitoring may exist in the sense that the local application or associated middleware may check the status of data synchronization and error out in the event of an exception. I refer to this as ‘local’ state monitoring. So under the EAI architectural style, state is managed locally, monitored locally (if at all) and is eventually consistent.

Under SOA, the driver of a business process is BPM orchestration in an independent process layer. In this case, we can say that state is managed centrally (in the BPM layer) and monitored centrally (also in the BPM layer). State in end-systems is updated progressively through the business process (via service calls) and so we could say that state is ‘progressively’ consistent as opposed to ‘eventually’ consistent.

Under EDA, there is no central or even local management of state. Instead, events signify distributed actions which together may be used to infer the state of a system. To the extent that any ‘management’ occurs, we could say that state is managed in a distributed fashion – one or more agents each acting on their own. Perhaps  it is more accurate to say that state is manifested globally. Converesely, state is monitored centrally within an Event Processing (CEP) layer which correlates events to infer system state. Under EDA, state is progressively consistent because the system is progressively reacting to events which are a by-product of a hidden or implicit business process.

Related posts:

1. Characterising Architectural Styles
2. Reductio ad Lucidus

• Asset - this is a core capability or “thing” that must be built, procured, maintained and managed in a corporate IT “inventory”.
• Element - these are the “atomic” building blocks used in the process of Composition.
• Composition - this is the mechanism which allows the different assets to work together to support a business requirement.

If we apply these characteristics to three common architectural approaches then we get the results in the following table.

EAI, although  unfashionable is still prevalent – even dominant in the industry. For EAI, we are primarily concerned with applications (usually COTS) which embody and support the requirements of different parts of the business. Multiple applications must be coordinated to support the whole business. The primary coordination mechanism under EAI is synchronization of state between the different applications – primarily via data integration. The composition element is the API.

SOA is characterised by Services as the key asset. Services are acquired or built to execute business operations. Elemental Services are composed to support business processes – a sequence of operations which results in a business outcome. BPM (or process orchestration) is the composition mechanism within SOA. The underlying functionality of a Service may reside in one or more applications, but from an SOA perspective this is of secondary importance…SOA is concerned with the Service, not necessarily its implementation.

EDA (Event Driven Architecture) is characterised by Event Services as the key asset which represent an asynchronous notification of an important event associated with the business. Elemental Events are correlated and further processed to derive higher-order business intelligence which may in turn trigger other Events. The primary composition mechanism within EDA is Event Processing (or CEP). An important part of this composition mechanism is the ability to manage or track system state.

This characterization gives more clarity to the difference between JABOWS and true SOA. Many so-called SOA projects have simply involved the “bottom up” exposure of application APIs using web-services standards – resulting in “Just a Bunch of Web Services” which don’t realise the business value of a true SOA. JABOWS is EAI because the applications are the core “asset”. A true SOA has a “top down” process-centric architecture with Services as the core asset.

Related posts:

1. Characterising Architectural Styles II – State

“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?

Related posts:

1. The Value of Enterprise Architecture
2. Design for Change
3. EA and Agile Projects

Communication is the key to ensuring that IT project deliverables provide cohesion across organizational, geographical and temporal boundaries. I have previously written that communication and governance are effectively the same thing. The problem is that “governance” needs to overcome the image of heavy-handed, top-down, hierarchical “rules” handed down by “out of touch” enterprise architects – like commandments on tablets of stone. EA must be seen as an enabler, not a roadblock.

But communication and governance must also be relevant to the organizational culture. So if the culture embraces agile development methods such as Scrum, then on the face of it the governance structure ought to conform with agile practices which favour direct verbal communication over documentation. If it is true that an embedded business representative can communicate requirements more effectively than a written requirements document, then perhaps it is also true that an embedded enterprise architect can “govern” more effectively than a written EA document.

However, on reflection, I don’t think the analogy of EA as a “customer” of the project is quite as strong as I first thought. There are a couple of differences between “business requirements” and “EA requirements”.

First, business requirements for a project are communicated primarily to that project. Few if any other IT projects would be interested in these particular business requirements which we are trying to encode into an IT solution. However, EA requirements must be communicated consistently across multiple projects and consistency demands that the EA requirements – the “governance principals” – need to be encoded in some written form, independent of an individual architect or even team of architects.

Second, business requirements change very frequently within the timespan of an IT project. Indeed the development process itself can change business requirements. This is why agile methods value verbal communication methods over written – so as to allow for frequent change in business requirements. EA requirements will not change as rapidly. Even though the Enterprise Architecture will evolve over time, it should not change over the course of a single project. Indeed if your Enterprise Architecture undergoes sudden rapid shifts (e.g. adopting an overnight SOA mandate) then you have a recipe for IT disaster. Hence the agile “insight” that written business requirements cannot keep up with reality, is not quite as relevant when it comes to EA requirements.

So my response to Paul’s comment is still: Yes! I agree that an EA representation on a Scrum project would be a good idea – to communicate, elucidate and interpret EA requirements to the project and importantly to take new lessons learned back from the project into the governance structures. However, this is no substitute for EA “documentation” – artefact-based governance – which is necessary to ensure consistency and continuity.

Related posts:

1. SOA Metrics, Projects and Organizations
2. The Value of Enterprise Architecture
3. Martin Fowler on Humane Registry

Continuity: EA provides continuity across organizational boundaries, geographies and – most importantly – the span of time. This is something that any individual project – successful or not – could not do. During the lifetime of an enterprise there are multitudes of projects executed in different places, by different people – outsourced and insourced. Ultimately all these projects must pull in approximately the same direction to support the business strategy.

To take a hypothetical example: “The data warehouse project in Bangalore being built by Tatosys must support the new marketing system being built in Sydney by Bluehair Consulting. And both are critical components for the mobile commerce platform slated for 2012 go-live by either PDQ Global Services or IBS (an HQ company) depending on who bids the lowest fixed price. And by-the-way the core transaction systems run on a mainframe that we are phasing out in the next three years as part of our 2002 strategic plan.”

Each of these projects is a major undertaking in its own right. Even if every project is 100% successful, you cannot be certain they will all fit together in a coherent and efficient manner. Making them fit is more than just a business problem. It goes beyond getting the functionality right and encompasses deeper technical layers of standards, frameworks and systems partitioning which are neither the domain of the business nor of business analysts.

Self Correction: The second value proposition of EA that I see is the role of “external observer and governor”. Enterprises exist in a constant flux of technologies, fashions, methodologies and business requirements. Someone needs to have the ability to evaluate new practices and make the decision to incorporate those that are valuable and relevant. This is not something that individual projects can do, although they may have a role in trialing new practices.

Each of these areas of change exist in the domain of different parts of the organization. The business is hopefully across changes in business requirements, the Project Management Office is (perhaps) across changes in software development methodologies, and the IT department always want to try out the cool new tools. But normally these parts of the organization don’t interact outside the constraints of an individual project. You need some constituency that is across all these areas and helping to guide the amalgamation of new “best practices” into the enterprise. I think that EA is the natural venue for this interaction.

So is this just the “old fashioned” value proposition of “EA-as-IT-planning”, instead of the cool new view of “EA-as-business-strategy”? I see it as something midway between the two. Certainly “EA-as-IT-strategy” is close, but also “EA-as-trusted-advisor-to-business-strategy”. Leave the business strategy to the business, but when it comes to the mechanics of implementing business strategy in terms of systems, processes and technologies, the strategy-makers should be able to rely on EA to guide them as to what works, what doesn’t – and who might take them for a ride.

Richard mentions that he’s “not convinced that the EA value proposition is understood by its customers”. I would go so far as to say I don’t think the EA value proposition is even trusted by its customers. EA needs to engage with its customers, figure out the value proposition and then execute.

Related posts:

1. Emergent Architecture
2. An Hypothesis
3. EA and Agile Projects