Fighting City Hall Just Got Harder - When Bad Ideas Become Industry Standards

Hardly had the proverbial ink dried on my white paper "Slicing the Gordian Knot of SOA Governance" when I found out that The Open Group (which I praised so recently for their TOGAF architecture framework) has issued a SOA Governance standard.

Their opening position is exactly what I think is wrong with the IT industry's concept of SOA Governance.

The architecture for those who think "scientific thinking" means "thinking about science"

And why do I think this is horribly wrong? Read my white paper to find out - it's free :-).

If you have problems downloading it from Slideshare, try mesfichiers.org or box.com.

On the Shoulders of Giants

Going through my SOA Governance white paper once more, I suddenly realised how many concepts and frameworks I was able to leverage in the process of proposing a "new" approach.

I'm reminded once more that even an "innovative" and unprecedented idea has to rest on prior ideas from other people. It's only proper that I formally acknowledge my debt to the following people and organisations:

• The BAIT Model: I think this came from the Meta Group, but I'm not sure. It's now such an established part of architectural scripture that its exact origins are now the stuff of legend. Anyway, whoever thought this up, thanks!
• TOGAF: The very name says it all - The Open Group Architecture Framework. My heartfelt thanks to The Open Group.
• Domain-Driven Design (DDD): I've always been impressed by Eric Evans's approach, and I'm glad I could build something on top of his work.
• Cohesion and Coupling: An oldie but a goldie. Stevens, Meyers and Constantine are to be heartily commended for what is perhaps the cornerstone of architectural analysis. If an architect understands no other concept, they should at least try and master the concepts of cohesion and coupling.
• Data on the Outside vs Data on the Inside: Pat Helland of Microsoft (at the time he wrote it) gets a much-deserved doff of the hat for this contribution. It's such a crucial piece of insight that it's amazing more people don't get it (Hey, you there using that outrage called Hibernate's "detached entities", I'm talking to you!)

In turn of course, I'm happy to offer the SOA Governance and SOA Management approach that I described to other practitioners to build upon further.

A Sanskrit verse comes to mind:

Na Chora Haaryam Na Cha Raja Haaryam,
Na Bhraturbhajyam Na Cha Bhaarakaari
Vyaye Krute Vardhta Eva Nityam,
Vidyaa Dhanam Sarva Dhanam Pradhaanam.

(No thief can steal it, neither can a king or government.
Siblings cannot ask for a share, and it's never a burden to carry.
It only increases when you spend it.
The wealth of Knowledge is the foremost of all wealth.)

Slicing the Gordian Knot of SOA Governance

Sometime last year, when I was working at WSO2, I was asked to write a white paper on SOA Governance. I made numerous attempts at this, and with each draft, I got lots of detailed technical feedback from some of WSO2's senior leadership team, but something wasn't working.

Ultimately, I realised that I had a fundamental philosophical argument with the whole notion of SOA Governance that I was being asked to write about. I felt that SOA was being overcomplicated and SOA Governance was a misnamed set of technology management tools. Now my problems with the white paper were not the fault of anyone at WSO2, because they were unfailingly patient with me. I finally realised that I had a problem with the entire SOA industry! Talk about fighting city hall...

To WSO2's immense credit, they let me go my own way instead of trying to force me to toe the industry line. They were gracious enough to tell me they would be willing to host any white paper I ultimately wrote, in their document library.

So I challenged myself at that point to "put up or shut up". If I thought the entire industry was wrong about SOA Governance, then I should at least put down in writing what I thought it should really be.

Well, it's been a whole year since then, folks, and the magnum opus is finally done!

I've called it "Slicing the Gordian Knot of SOA Governance - A Low-Ceremony Approach based on First Principles".

---

The impatient can go and download it right away from Slideshare. It's just 116 pages long :-). In case Slideshare is too hard, get it from mesfichiers.org or from box.com.

Important note: This is not a slide deck. It is a document in portrait mode, which Slideshare doesn't display well. I'm using Slideshare purely as a document sharing mechanism, so you'll have to download the document and read it off-line. It's too painful to view the document on-line.

---

I'm a bit exhausted right now, because the last week especially has been a mad rush trying to get this out the door. I have a workshop coming up on the 8th of December, and I want this out there so people will know what to expect when they sign up. Please write to courses@eignertech.com expressing your interest, and fairly soon!

Let me quote a few sections from the document that I think may be particularly interesting and counter-intuitive:

The four most important principles of SOA are dependencies, dependencies, dependencies and dependencies. We're not being entirely flippant in saying this, because there are four distinct “layers” in an organisation where dependencies need to be managed. These layers [...] are Business, Applications, Information (Data) and Technology.

“SOA Governance” does not mean the governance of SOA, any more than “scientific thinking” means “thinking about science”. [...] “SOA Governance” is about applying SOA thinking to governance, not about applying governance to SOA.

Governance is ensuring that the right things are done.
Management is ensuring that things are done right.

SOA Governance is determining what dependencies are legitimate at every layer of the organisation and identifying what existing dependencies fall outside this set.

SOA Management deals with how to remediate illegitimate dependencies at every layer of the organisation, how to formally document and communicate legitimate dependencies and how to prevent recurring violations.

Every expert unfailingly issues the standard disclaimer that SOA is not about technology, but the opposite message gets dog-whistled through the emphasis on products to manage web services, and ultimately prevails.

I hope that has whetted your appetite enough to make you download the white paper and read it.

I'm going to keep this draft version out there for a month or so. I'm open to all suggestions and feedback, and I hope to incorporate them into a final version that I will release before the end of December. I hope SOA practitioners and others will consider it a worthwhile Christmas gift :-).

Cheers and good night!

My Sydney Workshop on "Dead Simple SOA"

Those who've been following my writings over the past few years would know that I deeply believe two things:

1. SOA is a fundamentally important way of organising systems that leads to improved business agility, sustainably lower operating costs and significantly lower operational risk.

2. The "SOA industry" has needlessly complicated SOA in a bid to sell technology and consulting services, and this has caused many business and IT professionals in customer organisations to become disillusioned with it.

I've been working on a white paper that will comprehensively address how to "do SOA" right, and this will be released in the next few weeks.

I've also decided to take the plunge and take my ideas to market, so to speak. Over the past few years, I have written about many topics (SOFEA/Presentation, LIMA/Identity Management and SOA, of course, including the REST flavour of its technology implementation), and these have received very positive feedback, but also lots of follow-up questions. So I thought (entirely without vanity) that perhaps practitioners could benefit by being able to engage with me in workshops, think and talk through these ideas so they can go away with a much clearer understanding of these concepts. A full working day of "face time" with an author can be quite useful, I figured. So I've set up a company (Eigner Pty Ltd) dedicated to IT Architecture Education, in partnership with an ex-colleague, Rahul Singh.

As our debut offering, Rahul and I have organised a one-day workshop on "Dead Simple SOA" in Sydney on Saturday the 8th of December, 2012. (We have regular jobs during the week, so weekends are the only times that work for us.)

Who should attend? Architects and senior designers. It's not aimed at web service developers.

Topics:

• Learning “Dependency-Oriented Thinking”
• The difference between SOA Governance and SOA Management, and how to do each
• What are “services”? Defining service boundaries using the Cohesion principle
• “Data on the Outside” vs “Data on the Inside” – Interface design using the Coupling principle
• The 3 core components of a SOA ecosystem based on a Web Services approach
• Implementing enterprise “-ilities” (security, reliability, asynchronous communications) with REST

We've booked a classroom at the UTS Haymarket campus, and have also organised catering for lunch (sandwiches) and tea (mid-morning and mid-afternoon), so this should be a fairly standard training experience from a logistical perspective. However, I'm hoping the content will be anything but conventional. I'm audaciously aiming to change the way people think about SOA and send them home with a powerful new set of conceptual tools that they can use immediately.

We're pricing this one-day workshop at a very reasonable $495 inclusive of GST. If someone registers before the 24th of November, that's $440. We don't want more than 10 people in a single session, because it's going to be interactive with hands-on exercises and I'll be going around the room and having one-on-one chats with the participants. I wouldn't be able to do every participant justice if we had more than 10 in a class.

So if anyone is interested, or if you know someone who would be interested, please contact us by mailing courses@eignertech.com.

The course brochure is here.