An Acid Test for Enterprise Architecture
Later on, while at work, I started talking to my teams about the need to liberate all the Information pieces that we got in our Enterprise and to link them together. I had this vision of myself as the head of the CTU (Well, that's me… - at the age of seven I had similar narcissistic image of myself as Superman, and some decades later as bullet-proof Neo… blogging with integrity…), receiving an alert about a failed service and then hurrying down to the Information desk, while shouting:
"I want to know who's in charge of this failed Service – names, phones, departments; if the service is related to other services – I want to know that too. And find anything you can about this particular failure: who invoked the service and when, current and historic data (30 days back); I want to know where the invokers came from, what applications they used, what touch-points (IVR, Call Center, 3G Portal), what devices; I want to know which applications are behind the service provider – their underlying applistructures (app servers, databases…) and infrastructures – and I don't mind if they ride on the Digipede Network [for Dan :)] – I want the name, (IP) address, operating system and performance details of any PC or Server allocated in the last 60 minutes to the failed service's transactions. Oh, and if any one made any changes, in the last 7 days, to any of the underlying components – software, hardware, cables etc. - … then add the change details, name of the one who did it and name of the one who authorized it.
You got 5 minutes".
Let's deconstruct this scene.
1. Bill Buchanan (Head of CTU) is a Manager. It does not really matter if he's the head of the CTU, a CEO, a CIO, a Billing Dept Manager, a humanoid like Agent Smith, or... a business process. They all need a whole bunch of Information… now.
2. Buchanan's request was built in an ad-hoc fashion. There was no pre-defined query pattern ; there were too many "Oh, and…". But that's ok, given the next point.
3. Buchanan's request was communicated to Chloe, who's the Interface to whatever Information Buchanan might need. There's one and only one Chloe – don't expect a Manager (any manager) to wander around in search for Information! One Interface, one Chloe, one Ring.
4. Buchanan's request for Information was communicated in his Language. In our case it is POE (Plain-old-English) + the specific vernacular used by managers-level at CTU. If some sysadmin would have called Chloe, they would be communicating using a different jargon on top of POE, as Chloe masters all the different POE Jargons.
5. Buchanan specified two KPIs (Key Performance Indicators), in regards with his Information request.
An explicit KPI: "You got 5 minutes" (which means there's a deadline. Specifying a deadline makes it a real-time request, and have a look at this article on the meaning of real-time).
An implicit KPI: All the Information specified in the request must be returned. In the Real-Time Enterprise (and we will talk about this in just a second) the manager never accepts nor expects the following answer: "Sir, I have only a partial report. System A didn't respond fast enough; System B - well, you know we're in the middle of a database upgrade there…; and as for System C – gosh, I don't know what happened, but it crashed just as we tried to get the Information you requested".
Some would probably claim that these Information availability requirements are an exaggeration; most Enterprises don't need 100% availability and fast-response time.
I 100% disagree.
Most people are lazy thinking about doing the right things. "We don't have budget"; "We don't have time"; "We have other priorities". That's a political as well as a technical mistake. Political mistake – because as long as IT fails to provide real-time Information to the CEO and the other LOB managers with all kind of excuses, IT would Matter - with the worst connotation possible. IT must aspire at being completely transparent and non-existent. The biggest success of IT is to become an "IT doesn't matter" IT. It's a Tao paradox, but I am convinced it's true (and that's actually the simplest Acid Test for Enterprise Architecture...).
Technical mistake – having Chloe is not expensive and it's feasible (and see Always-On: Re-engineering the Read/Write Web and the Enterprise (with del.icio.us examples) for a partial Chloe implementation). You don't have to be Google or Amazon for doing it - anyone can do it if he or she wants to.
Buchanan finished analyzing the report that was generated by Chloe. And then he went back, this time with instructions: orders that have to be carried out, actions that must be performed. Again, Buchanan communicates – most of the time – with Chloe (who then makes all sort of calls to the tactical units while constantly typing).
Deconstruction time again:
Realizing orders and commands in the physical world is achieved, once again, by communicating with Chloe, the Information caretaker. I think this is so important and critical to the evolution of Enterprise IT as well as the Web that I must elaborate here with few associations.
First - Haeckel: Management-by-wire is managing by CRUDing the Business' Informational Representations, i.e. the Business symbols.
Second – the Tree: if a tree falls in a forest... etc. etc. Today we say: if your site/blog/feed was updated and Google didn't pick it up – did the update actually happen? For all practical purposes - it didn't! If you are a brilliant Professor, but you don't publish – does it matter? No it doesn't: Publish or Perish. In other words, if changes to the real world are not reflected back into the symbolic representation of that world - it is as if the changes never happened.
On the other hand, when a manager is manipulating the Informational Representation of any Business Object, it is as if the change has been done physically and directly on the real-world object - even if it didn't! That's the managerial power. The title of J.L. Austin's book "How To Do Things With Words" describes this power, and the French translation sounds even better, imho: "Quand dire, c'est faire" - When saying is doing. That's pure Buchananism – by manipulating the Information Representations through Chloe things in the real, physical world get materialized.
Well, I feel in debt to you, the reader, who wanted an instant Acid Test for Enterprise Architecture and got instead something that must be printed (!). So here's my compensation.
An Acid Test for Enterprise Architecture:
Any person or object (software, hardware, humanoid) should be able to Get or Set any Information, through one and only one Interface, using what the person, or the object, think is their natural (voice? English?) protocol of communication. If it's a Get, the most up-to-dated Information will be returned, in real-time, always. Failure is definitely and absolutely not an option! If it's a Set, the manipulation of the Information will trigger the necessary action in the physical world.
An Acid Test for the advanced Enterprise:
The Managers don't have to ask! The Information they might request (as a result of a real-time event), is already ready for them on their (virtual) desk.
An Acid Test for the really advanced Enterprise:
Not only the Managers don't have to ask for real-time Information, their post-analysis symbolic manipulation is carried out automatically. They are out of the loop. The Enterprise becomes autonomous.
Good bye for now.
This post is a sequel to Meant for Each Other: Enterprise Architecture and SOA