SOA, Achilles and the tortoise

Sometimes I have the impression that SOA is the tortoise that Achilles can never reach (as in Zeno's paradox).

For each process that can finally be automated and orchestrated with the Enterprise Service Bus there's some other that requires a native, peer-to-peer connector; for each one that is built to use the centralised Identity and Access Management service, another one pops up where some proprietary user management system must be used; for each workflow that is perfectly implemented with the enterprise BPM suite someone must come up with an urgent need of scheduling a sequence of batch jobs where somehow it is assumed that they will run flawlessly; for each pure SOAP or REST interface some ugly file transfer or share drive must come up; and for each shared service that is set up, someone will claim that their application is too critical, needs too much flexibility or time-constrained to use it.

Architecture is indeed an exercise in frustration, sometimes preaching in the desert, sometimes fighting windmills and other times being seen as a project risk.

More often than not, after all the negotiations and compromises that inevitably take place one of 2 things happen:

- if the architect conceded too much and allowed exceptions then something will go wrong. Usually the architect will be in a position to say "I told you so" but that won't help at all then;

- if instead, the architect sticks to his guns defending the best way to implement a system even against strong political forces, then over time everyone will start realising the advantages and using them to their benefit which is the best reward the architect can get. He will take no credit for it though - someone else will instead advertise how smart he was for reusing some component that the architect had spent years to get agreement for deploying as a shared service.

Ultimately being an architect is something that one must do with passion and find the reward in his own work. After all it is a great job. Also, after a few years a certain reputation does build up - for the best or for the worst.

But no would-be architect should ever think that it's all glamour and respect.

Double kernel in Windows - Why not?

As a Windows user I am, as much as everyone else, regularly annoyed with the Windows Update process. Booting the computer to look at a screen saying "Configuring Windows Updates - don't turn off your computer" is just not fun. 

So why on earth doesn't Microsoft do something about it?

Here's a thought: why not use a double kernel? You know, like double-buffering for rendering video.

The PC would have 2 copies of the OS. While the user was working on the active image the other one would be updated in the background. Then the user would be automatically switched over to the new version. The old version would be synchronised with the new one to get ready for the next update, and so on.

It's actually quite simple. 

Another way is to embed Hyper-V in the normal Windows distribution and turn every PC into a virtual cluster. This might even be simpler.

Either way, anything would beat the darn update process.

A TOGAF 10 wish list

I do admire the TOGAF framework as a way of organising work.

It's logical and complete and it can be flexible enough to adapt to different dimensions of scope so it is, in my opinion providing the most value in supporting programme management. To be honest I don't think that it is realistic to use any framework (be it TOGAF or any other one) in a full enterprise-wide scope. But for programmes, why not?

There are however some things in TOGAF 9 that have the retro look of a science fiction movie from the early 90's. In most cases they are optional and I think that they should not even be part of the framework. TOGAF should describe, not prescribe.

Here are some ideas that in my opinion would, so to speak, bring TOGAF 10 to the 21st century:

1. Get rid of the outdated (almost funny except that they aren't) reference models.
I mean, what is the meaning of the Technical Reference Model, shown below? I mean, really... "Graphics & Image"? "Operating System Services"? Maybe (and I'm not even sure about that) this had some meaning back in the far past....



(Source: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap43.html)


And then there's the III-RM. Again...




(Source: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap44.html)

It's not even worth starting a discussion is it?

Rather, instead of these simplistic and rather useless reference models The Open Group should create a community that would itself create and update reference models for all sorts of different purposes. These could be, e.g. reference models for business intelligence, document management, master data management, high performance computing, big data, advanced analytics, cloud integration, you name it. From the reference models architects could then create their reference architectures, suited to the needs of their organisations.



2. Replace Architecture Building Blocks" (ABBs) for Application Services. ABBs just don't make sense. Solution Building Blocks (SBBs) are real components, while ABBs are supposed to be logical components. But what does that actually mean? Ultimately the customer needs a service, not a logical component.
The service can be realised by an SBB or it can also be outsourced for example. And that's all there should be to it.


3. Introduce Archimate as the "lingua franca" in TOGAF at all of the logical layers. It is now owned by The Open Group anyway... and it's really good, too.


4. Require methods for designing and evaluating architectures. Here I am thinking in terms of ISO2000 and ITIL. ISO2000 requires processes and ITIL describes them. In this case I would recommend the SEI methods ADD (Attribute-Driven Design) and ATAM (Architecture Tradeoff Analysis Method) at least.