Friday, March 31, 2006

Organizational Architecture for the Real-Time Enterprise

I was known to be a "Reorg" freak, pooling out people from their daily jobs and giving them an ad-hoc assignment based on their talent. In these unexpected attacks on my descent, hard-working employees I was entirely disrespectful to their title, official expertise or their department. Whoever had the required combination of skills and personality was a candidate for a reassignment. Thus, for a risky cross-organizational and political project, I pooled out a DBA who I knew to be both highly human-oriented and a "take no prisoners" kinda guy. Sometimes, I was engaging bright-minded and motivated geeks in covert missions, so their managers who reported to me wouldn't be able to use it as an excuse for delays on delivery.

That was an "early adopter", beta version of what I call flat, ESDR organization. To better understand this concept and for having guidelines on how to implement it in your own organization, please keep on reading.

Endless Unpredictability

Paradoxically, what is mostly missing in the real Time enterprise is nothing else but Time. The more real is Time, the more it is absent. The rapid changes in technology, business and trends created a context in which Enterprises have to cope with an endless flow of unpredictable events. This lethal combination of endless and unpredictable is what kills Time and what puts Enterprises in peril. It is possible, of course, to ignore events, but that implies missing a potential business opportunity or a critical fault that has to be taken care of ASAP. Enterprises, therefore, must transform themselves into real-time management and control machines, capable of processing endless, unpredictable events and react to them in no-time.

What is ESDR?

This transformation requires different strategy, structure and architecture in any Enterprise dimension: organization, processes, applications, infrastructures and so on. What applies to the Enterprise as a whole, applies no less to each of its components.

The architectural principle underlying the no-Time Enterprise is ESDR, which stands for Events, Services and Dynamic reallocation of [general purpose] Resources. The real-time Enterprise is all about on-the-spot capturing of Events and reaction through Services, to which Resources are dynamically allocated. The entire process is policy-driven (or business rules driven) and it runs for ever and ever. Currently, the only domain that has full-blown slideware of ESDR is that of Utility Computing, but that's another story.

The ESDR architecture is radically different than that of the current Enterprise. Until recently IT organizations were managed without any IT Governance solutions, meaning that most of the CIOs and the other IT managers couldn't have a real-time, detailed, and open view on their own business. Yet, having this kind of Information is only the first step; in itself the Information is a dead horse (NSA had the Information before the 9/11 attacks!). So in the real-time Enterprise the Information must be available, but it also has to go through constant processing, alerting, and reaction. And the reaction is not allowed to fail on technical issues like availability and performance. Hence, the DR in the ESDR architecture - the ability to dynamically allocate and reallocate resources at run-time.

General Purpose Resources

In the past, every Resource had a function to which it was statically bound. For instance, once a Sun server has been designated as the Billing database server, it remained so until its end of life. And if repurposing was considered – well, it was considered thoroughly: nothing that a real-time Enterprise can wait for.

For the ESDR to be well optimized and cost-effective, it is preferable to have general purpose resources. A single-purpose resource is more likely to have an idle time (which is bad) than a general purpose one. For example, in the past servers were capable of running only the OS of their vendor. Sun boxes could only run Solaris, IBM Mainframe - only the Z/OS and so forth. That's an example of a single-purpose resource. If a utilization peak or any other kind of failure happens to an application running on a Windows server, it is impossible to reuse the idle Mainframe partition in order to recover that application.

Most of the organizations are structured in the same single-purpose/single-function manner. A storage manager working in the storage team is (conceptually) bound to its team for good. He's a single-purpose resource. If the DBA team is short in manpower for a certain project – they wouldn't look for "spare resources" in the storage team.

The single-purpose inefficiency is bad for dynamic reallocation, and therefore most of the vendors have reengineered their resources as general-purpose ones. A Sun AMD 64-bit machine is capable of running Solaris 10, Linux and Microsoft Windows. Same for the new IBM server families, which are capable of running IBM proprietary OSes as well as Windows and Linux.

As you will see, the real-time Enterprise is adopting the same general-purpose rule for the new staff member's profile. The more multi-functional and general-purpose a staff member is – the better. She must be an expert in one domain – say storage administration or Java programming, but she's also expected to be good enough in Unix administration or in Python. Because when she's idle, she then can be easily repurposed.

A Case Study

The following is a case study of a real infrastructure group that could no longer process and react to the endless, unpredictable flow of events (i.e. request for infra additions, system changes etc.).

The Enterprise was suffering from repeating infrastructure failures and downtimes.

Customers were complaining about delays in delivery time, about the quality of the deliverables, and about bad customer experience in their interaction with the members of the infra group.

The employees of the infra group complained (in their turn) about insupportable customers, who were always coming at the last minute with an ASAP request; about arrogant customers who treated them like technicians, rather than engineers, refusing to provide meaningful details about their project; and finally about "ongoing" – a never ending list of tasks that eliminated any possibility to do something new and exciting.

Briefly, an Enterprise Classic (Or, "When the CIO is giving a call to the nearest IT Outsourcing shop").

The Infra Group Structure & Staff Profile

This group had the traditional, function-oriented infra organization structure: a group manager, department managers and team leaders, with each team representing a single function, such as "Unix system", "Storage", "Databases" and so forth. Each team was a silo with minimal interactions with the other infra teams – except for crisis time.

Team leaders were professional geeks, who've been promoted because they were so damn good in what they were doing. But as you can imagine, they were not necessarily as excellent in tasks management…

The department managers, each in charge of several teams, were mostly veterans in their domain: no longer geeks but highly experienced.

Interaction with the Infra Group

As said, each team was functioning as a silo. This was not the outcome of a structural design – it simply happened this way. Therefore, when project managers from across the entire Enterprise needed an infra solution, they had to deconstruct the solution into its components and open a request with each of the infra teams. For instance, if a PM needed a database server, she would file a request against the unix team, asking for a server; the storage team – asking for a storage; and the database team, asking for a database. She would then coordinate the infra teams to have her solution ready on time.

This is a classical point-to-point integration: PM-->db, PM-->storage, PM-->unix – a logical way of integrating with resource in the pre-SOA, point-to-point era.

Some more findings that no one should be surprised about:

1. The human interaction between the infra teams and the rest of Enterprise happened through mails and corridor chats. No methodical way to open requests and to track them down.

2. After a while the infra group did place a front-end system through which PMs and whoever else could open requests to each of the teams. Finally, the actual amount of work became visible, and it was indeed an endless list of to-do tasks.

But a fundamental management issue remained unsolved. Because of the silo nature of the teams, their tasks were not inter-linked nor did they point to the external project that created them. There was, therefore, no way to pin down the tasks that are part of a certain project; there was no way to track down the progress of an external project inside the Infra group, or to prioritize it.

3. Most of the work was done from memory. Even though many of the tasks repeated themselves (creating a database, installing a server, allocating storage etc.) the teams were not using the pre-automation minimal quality guarantee, also known as the check list. As experienced as they were they couldn't beat the devil who's been lurking in the details.

4. The lack of management was visible in other domains as well. Neither consolidated nor up-to-dated asset management existed; no impact analysis of potential changes or of run-time failures was possible, and so forth.

Final Note

A complete lack of governance and an inability to manage & control yielded the inevitable consequences described earlier: exhausted employees, dissatisfied customers, and unplanned outages of Enterprise production systems.

Which is why the flat, ESDR restructuring of this group was so critical.

In the next post I will explain what the flat thing is, and describe the new ESDR strucutre of that infra group.


Post a Comment

Monday, March 20, 2006

Trust, In a World Built In Code

I have never thought about Open Source as a mean to protect the users at the ends of the network. Open Source has been injected into my knowledge system as a great way for bootstrapping a project and having quality software and quick bug fixing; as a genial door opener (through a no-cost software) in what has been for years the unique playing field of Enterprise Software Gorillas; and as a fantastic contributor to the commoditization of infrastructures, allowing innovation to occur at higher, functional levels.

Yet in all these years I have never heard anyone talking about Open Source as a mean to protect me, to secure my well-being, or to guarantee my personal freedom.

Then last week I stumbled upon a short paragraph which caught my attention and changed my perception:

Code is the technology that makes computers run… that directs the functionality of machines. These machines – computers – increasingly define and control our life. They determine how phones connect, and what runs on TV. They decide whether video can be streamed across a broadband link to a computer. They control what a computer reports back to its manufacturer. These machines run us. Code runs these machines.

This paragraph is an excerpt from Lawrence Lessig's 3 pages introduction to "Free Software, Free Society, Selected Essays of Richard M. Stallman". Strangely, my knowledge about Stallman has been so far limited to trivial facts and images: bearded man, long hair, GNU is Not Unix and other nonsense. I don't get how the knowledge about this man and his philosophical work has eluded me so far, because as you will soon see Stallman's ideas are pertinent to many of today's burning issues (that doesn't imply that we have to accept his ideas; we should, nevertheless, inject his ideas hard into the mainstream conversation).

Back to Lessig's excerpt, the analogy between code and law is what made me jump. "But, of course! "Code Napoléon"; Code of Ethics etc. etc." – code is what defines behavior, organizations, and societies. We all learn to know each of the contextual codes we're associated with – home, work, state etc. – and behave accordingly. Which means Code regulates us, governs us. Code is Law, and Law in Free Societies is open, accessible to anyone and modifiable.

Lessig continues with the inevitable questions that anyone should ask once this meaning of code is revealed.

What control should we have over this code? What understanding? What freedom should there be to match the control it enables? What Power?

These are simple questions that are simply relevant to the discussions about privacy over the net; about Google and its overwhelming potential of becoming evil; and of one of the hottest clichés of these months – the Attention (O'Reilly's eTech theme for this year). I dare referring you to all my Google articles (see the side bar for categories) to see that Stallman's work and ideas are relevant. They are sort of a solution to all the above mentioned problems. Here's a final quote from Lessig's Introduction:

These questions have been the challenge of Stallman's life. Through his works and his words, he has pushed us to see the importance of keeping code "free"… in the sense that the control coders build be transparent to all, and that anyone have the right to take that control, and modify it as he or she sees fit.
This is "free software"; "free software" is one answer to a world built in code.

Google, Yahoo, AOL, Microsoft and all the emerging SaaSers, such as – open your code! It's tough, but you can do it progressively by using, for instance, an equivalent to the recently published Microsoft Reference License (MS-RL) – "a reference-only license that allows licensees to view source code in order to gain a deeper understanding of the inner workings of a Microsoft technology. It does not allow for modification or redistribution".

Can you imagine how much Trust will be introduced into our world, as well as to our life, by granting access to the code that run our virtual existence? Naturally, this raises issues of Intellectual Property, Commercial Secrets etc., but as Stallman says: "There are always numerous ways to organize any kind of business".

Or, we can spend our life before the Law. Just like in Kafka's "Before the Law" parable, we're standing today before the Doors of the Law and we're denied access to it. We can react like the subject in that parable and wait till death for an authorization that will never come, or we can take the law in our hands. As Slavoj Zizek (in "Contingency, Hegemony, Universality: Contemporary Dialogues on the Left") explains:

The subject failed to include himself in the scene, that is, to take into account how he was not merely an innocent bystander of the spectacle of the Law, since 'the Door was there only for him'.

Stallman has devoted his life to fight all the guards that stand before the Doors of the Law ("My 22-year-old child, the Free Software Movement, occupies most of my life, leaving no room for more children"). Yet, I must make clear that Stallman's ideology about free software is much broader than what's been described in this post. It is also much less "fear-driven" and much more "social-sharing and happiness-for-all" driven.

It had not been known to me prior to reading Stallman's book that "Free Software" and "Open Source" represent two different ideologies and credos. While Stallman's Free Software Foundation promotes free society through free software, the OpenSource Initiative promotes open source as a mean to increase productivity, as is stated in their home page:

The basic idea behind open source is very simple: When programmers can read, redistribute, and modify the source code for a piece of software, the software evolves. People improve it, people adapt it, people fix bugs. And this can happen at a speed that, if one is used to the slow pace of conventional software development, seems astonishing.

I mention this because undoubtedly I was a product of the Open Source movement. I am glad I came to know this other movement, FSF, which provides me with so many interesting ideas to grok.


Richard M. Stallman

Free Software, Free Society: Selected Essays of Richard M. Stallman

Richard Stallman's Personal Page

Richard Stallman - Wikipedia, the free encyclopedia

FSF - The Free Software Foundation

Lawrence Lessig

Lawrence Lessig

Introduction to: Free Software, Free Society, Selected Essays of Richard M. Stallman

Lawrence Lessig: Bravo Microsoft (Lessig welcomes Microsoft's Shared Source Initiative and an interesting discussion about the Orwellian nature - or not - of Stallman's free software concepts evolves)

Stallman and Winer

Richard Stallman: Response to Dave Winer on Python Licensing
Doc Sealrs take on Richard Stallman: Response to Dave Winer on Python Licensing
Dave Winer : What is Open Source?


By Anonymous Aurélien, at 6:22 PM  

You should read the future of ideas next.
You'll see that Stallman's fight for the freedom of software is not limited to software but expends to all aspects of life. It is the fight for "the fate of the commons in a connected world" as Lessig puts it.
The "pronetariat" versus the info-capitalism... And don't get me wrong it is not about a new class struggle.

By Blogger Muli Koppel, at 8:36 PM  

Salut Aurélien

It took me some time to figure out what "pronetariat" means. Anyway, thanks for your references, I will certainly look into them.


Post a Comment

Monday, March 13, 2006

Faustian Deals and Magical Clipboards: Ray Ozzie's Ultimate Mashup

Faustian Deals

Many of us are still pretending it is nothing but a harmless win-win exchange deal: The Internet Giants (Google, Yahoo, AOL, MSN...) provide us with free services that we like, and in return we allow them to implant ads wherever they see fit; we gain a choice of great, free services, and they make their living through advertising - a fair deal.

Only, there always has been an untold and implicit addition to that deal – some kind of a devilish exchange in which we trade our Personality and Identity (as reflected in our data) in return for those free services. Devilish - because once the pact between a user and a Giant is signed it is as irreversible as the pact Dr. Faustus had with Mephistopheles. The Giant's confines become a prison for life.

Clearly, such serious allegations demand factious supporting arguments. I'll start, than, by making sure we're on the same page regarding the equation between Data and Identity. Let's take Google, as an example (we can take instead any of the Internet Giants). By using Writely, Gspace/GDrive, Gmail, Gtalk, Google Reader, Google Base, Google' search history, Google's Accelerator, Blogger and so forth, I am, for all practical purposes, disclosing my own self in its digital format. What Google is getting in return for its portfolio of free services is a concrete, tangible virtual self. How do they treat this precious asset – do they consider it a deposit, a gift, or probably they consider these virtual selves as part of their own estates? Let's find out.

Here are three simple tests that allow us to asses whether a Giant-User deal is a devilish one or not. All the tests refer to a scenario in which a user has been using a Giant's free service for a while.

Test#1. Can the user reuse her Data as she wishes?
Test#2. Can the user get his Data out?
Test#3. Can the user destroy any traces of her Data from the repositories of the Giant?

Based on my experience, these three tests usually fail. It's a lockdown! An asymmetrical relationship. Once our Data is at the Giant's confines it can be reused only as part of the Giant's processes (and see Organizing the Information of the World for an analysis of this exact issue).

Getting the Data out encounters numerous obstacles: it is impossible, or impractical, and/or inaccurate. Impossible: in the early days of Gmail, Contacts could only be imported into Gmail but not exported (again, this is just an example). Impractical: I don't know of any practical way to export mails out of any free mail service. Inaccurate: sometimes, as it's the case with some photo sharing sites, the exported content is degraded in quality. Briefly, there's no easy way to take the data and run.

As for destroying user's data stored in the Giants' repositories, I'd say "forget it". Check out Gmail Cancel Account, for instance - you won't find a single word about purging or destroying your mails.

To sum up, the whole situation is paradoxical. We, the users, create Data which practically we do not own. As Dave Winer pointed out: "We're the users in a user-generated content" We are not the owners; the Giants are, or behave as if they are.

Free (as in Freedom)

Clearly, these services are not "free, as in freedom", though I doubt this alleged freedom ever existed nor that it will exist one day. And yet, many voices were questioning the Giants-Users relationships, righteously claiming that the Users should have complete ownership and sovereignty in regards with their own digital Personality and Identity. Interestingly, there's one Giant who openly discusses these issues, and surprisingly it's an ex-bad-guy: Microsoft.

Last November, Ray Ozzie, Microsoft's CTO, published a post on the Simple Sharing Extension (SSE), a Microsoft extension to RSS that enables bi-directional synchronization. In that post, Ozzie admits that "The websites, services and servers we build seem to all want to be the “owner” and “publisher”; it’s really inconsistent with the model that made email so successful and the loosely-coupled nature of the web".

Ozzie speaks here about the entire software industry and the way applications are designed (and consequently built): applications are not designed as placeholders for user information, but rather as the owners of that Information. Therefore, they are not provided with means to share, export and destroy the Information they store, unless, of course, it is part of their processes.

When it comes to Microsoft, things were really bad, as Gary Edwards points out:
Microsoft made their billzillions from tying information to specific application and platform versions, and tying those to hardware and API references, charging a premium for the licenses needed to facilitate the exchange and interchange of documents. Just the opposite of the Internet centric Google model.
Though I agree with Edwards' description of Microsoft, I entirely disagree that Google is making any difference whatsoever. The sheer usage of standards (opendoc, openoffice, atom, rest etc.) doesn't make a company an Information Liberator! I think the three tests above prove it well.

There's clearly a need to liberate the Information from their silos, and thanks to Dave Winer, who doesn't believe in passive preaching, the web had turned into a RSS pipe. Yet RSS is a machine-to-machine protocol, and so there's still a need to provide the users with a simple way to take their Data and run. RSS will most probably be the infra-standard, but it is not an end-user' solution.

The Ultimate Mashup

Last week Ray Ozzie published what is a direct sequel to his November' SSE post, titled "Wiring the Web". "This is where my head has been at the past several months", says Ozzie, "I’ve been wondering, 'what would it take to enable users themselves to wire-the-web'?".

Users will not wire the applications of the web - they are users, not geeks! What Ozzie's referring to is a simple way for users to take their Data from one app to another. Wiring the Information of the Web: the ultimate mashup architecture. No APIs, no Feeds - just Information on User Interfaces and an ability to take it from one UI to another. To me, that's the most evident requirement (and see An Acid Test for Enterprise Architcture, as well as other posts in this blog), but I don't remember any Giant discussing it so openly - after all it might become the magic flute saving Information from the Giants' silos. Indeed, for a company that was said to miss the Web 2.0 Wagon, that is a sweet sort of revenge.

In Ozzie's vision, there's some kind of a Live Web Clipboard through which Structured Data, i.e. semantically agreed Information, is tunneled. This is practically impossible nowadays, as Ozzie explains:
"The excitement on the web these days is all about 'structured data' such as Contacts and Profiles, Events and Calendars, and Shopping Carts and Receipts, etc. In most cases, the structured form of this data, which could be externalized as an XML item or a microformat, generally isn’t. It’s trapped inside the page, relegated to a pretty rendering".
So Microsoft, through Ozzie, is talking about an infrastructure that not only will enable users to take their data with them but will also enable a seamless porting of that semantically agreed data into another application. Everyday Users without any programming skills will be able to reuse and move around their Information as they see fit.

We can see the Infrastructure of the future shaping up: RSS+ SEE, Semantic Web, i.e. semantically agreed XML structures embedded inside the RSS Feeds, and then some kind of a Web Clipboard that will allow the Ultimate End Users Mashups.

I had a strong déjà vu when reading Ozzie's Wiring-the-Web, with scenes from Minority Report, where Tom Cruise stands in front of multiple room-size screens moving Information rapidly from side to side. Ozzie's demo and documentation of the Live Clipboard are certainly not hinting at that, but who knows: maybe Ozzie had a similar déjà vu?

Minority Report Clip [watch the first 5 seconds... that's the best I could find]


By Blogger Meir D, at 4:18 PM  

Muli, great post, agrre with all of my heart.
Meir Deutsch

By Anonymous Robert W. Anderson, at 5:26 PM  

Great post -- great blog. One of the things that I'm interested in is that I assert that I own my data (and agree to share it with these providers). The provider should tell me what they do with the data, and I prefer services that don't lock me in. These are roughly the principles that the AttentionTrust is trying to get people to adopt.

By Blogger Muli Koppel, at 7:15 PM  

Hi Robert,
Thanks for your comment.
It's interesting what you're saying about AttentionTrust. I thought that they are dealing with the capturing of the gestures (clickstreams) generated by the user as part of his visit to a site, feed etc. I didn't know that they are also dealing with the capturing of the explicit content a user is creating within a service, such as mails, photos, documents etc. Also, while it's easy to capture clickstreams, I don't understand how they plan to capture content.

By Anonymous Robert Anderson, at 6:02 PM  

My point wasn't really that the AttentionTrust solves this problem, but that their principles get at the root of the issue: who owns the data.

You are correct, the AttentionTrust is not trying to capture content; however, they aren't actually trying to capture clickstreams either. They are trying to give users control over their own attention data. If this means an Attention Recorder, OK, but that recorder is just a tool to help the user understand their attention data and to possibly participate in markets for that data. The existence of the recorder helps users assert to the silos (e.g., Google) that the user also owns a copy of that data. I wrote a post on the recorder recently AttentionTrust != Spyware.

Freeing ones content from the silos is a whole different matter. I think that users need to assert that they won't use services that attempt to "own" their data. For example: I recently started using GMail. I know that I can get my data out using POP. That is OK for me. If I could never get the data out, I never would have tried GMail in the first place.

Post a Comment

Wednesday, March 01, 2006

An Acid Test for Enterprise Architecture

Chloe O'Brian

The first season of 24 gave me a lot of ideas. Well, I wish it was related to Jack Bower, but no, it was more related to Chloe O'Brian (Michelle Dessler, I think, at that time). I was simply stupefied by the way Information was flowing and flying from one side to another.

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:

Bill Buchanan

"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 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


By Anonymous Gabriel K., at 11:46 AM  

Great article, as usual!
In fact I also find 24 very interesting but for historical and socilogical reasons.
First: there could not have nay 24 without the invention of the cell phone. No cell phone, no action. The cell phone just made many things possible - and many other things impossible, as "waiting for the phone to ring", "trying to reach someone for an appointement in town", etc. Many funny things in Seinfeld for instance could not work anymore.
Second: the sociological point of vue: a) Jack Bower is a Hero, in the antic sens. Strange, in our times we need heroes. And b) there are all real professionnals. Only Chloe seems to have personnal feeling that interfere with her work. Neither Jack Bower, nor Michele, nor anyother, nor the guy who comes for 10 seconds to do a small job: all are real professionnals, with a pro attitude, always talking about scheduals, time, etc.
Now, the "information" part: I think you said all the points! One thing that often bothers me: Chloe is alone. No replacement (I only saw sean 2 and 3 (not until the end)). I like that, this is real life, often managers say "you are repleacable". To me, I only saw the absolute contrary : no one can be replaced. If one change one person, one change how the system works.

By Blogger Muli Koppel, at 3:08 PM  

Thanks Gabriel for your kind and interesting comment.
I'll pick your last point for a follow-up:
Complex organizations are usually capable of overcoming the loss of a talented employee, as critical as she would be (…Carlie Fiorina, for instance). Yet, as you mentioned, the organization will never be the same again. That's the power and the legacy of a "replaceable individual".

By Anonymous David Sachs, at 2:34 PM  

Muli, A facsinating way of observing the chain of command and processes.

Always an admirer,

David Sachs

PS One might want to mention the readers that "Deconstruction" was Derrida's methodlogy for reading into texts and flows while showing that they may be viewed and understodd excatly the opposite of the common thought. It's a facsintaing job of decontruction that you've done...again

Post a Comment