Should Your Next CEO Be a Philosopher?
In the previous post, Organizational Architecture for the Real-Time Enterprise, I described an Infra group incapable of coping with endless, unpredictable events. Systems were falling, customers were angry, and employees were eroded and frustrated. Things like that don't happen out of the blue, and therefore an environmental context, which I believe was the root cause of these phenomena, was presented in the first part of our story.
I was called to re-architect this group, and so I thought… why not transforming it into a real-time Enterprise organization?
To accomplish that, several things at the organizational level had to happen: few machines had to be introduced, and the organizational structure had to be modified. As for the machines – those included event listener and processor, services and SOA hub, as well as a utility computing engine, capable of dynamic reallocation of general-purpose resources. As for the organization structure – it became flat: no hierarchies, no managers.
After this intro, we're ready, I believe, for some more details.
(If you haven't read the first part of this story, I assume the following would be somewhat decontextualized).
As I described in the Socio-Politics of SOA, point-to-point is a powerful social paradigm. It creates trust among individuals – a social texture that is highly important and advantageous in times of crisis, failures, bugs and so forth. And yet, from a management perspective, point-to-point is a nightmare – no formal documentation, difficulties in tracing, monitoring, validating and controlling. And there's no reuse.
The point-to-point links - PM->Storage team; PM->DBA team; PM->Unix team etc. - had to be removed, as it created sort of a black hole, sucking whatever management-related Information into a total oblivion. Hence, the first architectural component introduced was…a HUB.
The full name of the hub was the I/O Hub – input and output hub. Whatever came in and whatever went out, had to go through the I/O hub. Customers' requests and requirements were filed against the hub, and it was the hub that provided delivery dates as well as the actual deliverables.
At this early stage the hub consisted of two-three highly representative and customer-oriented folks (I called them the foreign ministers of the Infra Group), with whom the PMs and whoever else interacted from then on.
The rest of the Infra group went underground.
It is amazing how powerful this simple concept of a hub is, and how much benefit it brings. The Hub is inherently an Agile construct, meaning it is suitable for endless internal optimizations, without affecting its interfaces to the outside world (in our case – to the PMs). All the following functions were added to the I/O hub progressively:
Capturing customer requests; analyzing their impact; performing a cross-infra high-level design (impossible in the point-to-point era); building work plan; invoking services; allocating resources to the services; communicating delivery dates and providing regular progress reports to the customers; verifying internal progress of execution; monitoring delays; verifying quality of deliverables and on and on and on. Endless functions can be hosted by the hub.
With an I/O Hub the management Information is abundant. You can slice it and dice it, have reports or real-time alerts, present it in portals or in management dashboards. The hub is the land of endless possibilities.
Centralized or Decentralized?
For those of you who dislike the centralized nature of the hub and would rather see a scalable, failure-free decentralized architecture, similar to Skype's peer-to-peer, I would say that in order to get from chaos and disorder to a robust decentralized architecture, there must be an interim, centralized, hub phase. Only when management is reinstituted, that it can be deliberately federated and deconstructed, keeping the management principals vivid in the new decentralized reality. In any case, never confuse point-to-point with decentralized architecture. Point-to-point is not architecture.
Once the human I/O hub was in place, the time has come to introduce the Services layer. While the role of the Hub is to make sure management happens on the organizational level, the role of the Services is to make sure management happens on the functional level. Here're some points that will clarify things a little:
1. Services are the automation starting-point
Services create clear limits. Installing a server is not installing a database. You think "Wow" – that's trivial, but having clear boundaries is not that easy. Actually, most of the organizations I know are seriously suffering from ill defined boundaries, too much gray areas, overlapping responsibilities and so forth. So boundaries are important.
Now remember that this infra group used to work from memory – without checklists. I could tell them (which I did…): "Ok guys, you got one month to create a checklist for whatever you're doing!" but then most probably they would have scratched their heads trying to figure out where to start, and where to focus their efforts; for there are so many things they were doing… from memory. Hence, Services. Once we have defined the Services, it was a straight forward task to create their underlying checklists.
Once the checklists were defined, they went through several cycles of testing until they got the quality seal. This was a great step towards quality assurance of the infra group deliverables.
At this stage, the checklists, like the I/O hub, were executed manually. But now that they finally existed, it was pretty straight forward to launch a "checklist automation project".
Which services to automate first?
Using the management information provided by the I/O hub, this question was easily answered. Automation was first planned for the "most wanted" Services.
2. Services are traceable units of work
Another important point in managing tasks and projects is that Services hosted in a services' hub are traceable units of work. SOA hubs provide natural BAM/BPM/SLM information, eliminating the need for other tools in this space (didn't we say that SOA=aligning IT with Business?)
In our case study, the I/O Hub provided detailed reports (and online Information) on:
A. Services – execution time, num of requests, SLA, problems, most wanted/less wanted services;
B. Customers – who, what, when. Top services per customer and so forth.
Summary: Services create clear functional boundaries; they stimulate automation and consequently quality; and their host – the SOA hub – provides indispensable insight upon the overall performance of the projects and tasks that use them.
SLA and Contracts
Services do not have an intrinsic SLA. This is defined for each Customer-Service relationship. Some customers need Service X to be executed ASAP, while others couldn't care less if Service X would be executed a week after their request. As there's no accounting to tastes, there's no point in trying to "convince" the customers about the "right" SLA for a service. Give them each what they want.
It's time now to execute the Service. But for that we need some Resources.
General Purpose Resources
When examining each line in the different checklists of the different services, it becomes clear the many services rely on the same resources. Scripting is a good example – almost all technical services need scripting. Basic level UNIX administration is also something required by many services, etc. etc.
Apparently, most of us are innately multi-purpose resources. In our case study, it turned out that DBAs have basic, yet solid understanding in system administration; that UNIX administrators have good knowledge in storage administration and vice versa; that most of the group members were scripters; that some were natural project-managers, and that others excelled in problems resolution. Each employee had a variety of skills ranging from "basic" to "expert", skills that were not necessarily related to his/her job title!
So we made a table of all required skills (the required skills were deducted from the Services created in the previous step). Each skill had 3 levels: basic, advanced and expert and each employee was mapped against the different skills' levels.
This is how we mapped our [human] resources and created a platform for dynamic resources reallocations. We made each single-purpose resource (for instance, a storage manager) a general-purpose one by exposing the variety of skills that each employee had.
Finally, to guarantee the future availability of general purpose resources, the HR group was instructed to have a clear preference for multi-purpose candidates.
We have restricted ourselves to a one-week reallocation of human resources. At the beginning of each week, every employee was receiving his/her weekly tasks. Usually, those tasks were in his official domain of expertise, but in other times, he was doing work for other Services that required his skills.
As said before, it was the I/O hub that generated the weekly tasks list.
"The World is Flat" and so is the Real-Time Enterprise
As you remember, the infra group team leaders were super geeks - experts in their domain. In the old, function-oriented organization, these experts got promoted to team leaders' position, thus becoming the endless tasks managers of their teams.
The Department Managers were veterans in their domains, and their function was to manage their managers.
This is a classical hierarchy in an organization where change is predictable, and therefore the structure reflects a chain of command and control. When the CEO says something it filters down through the entire organization's hierarchy. There's Time for that – change is predictable.
But in the real-time Enterprise there's absolutely no Time for going through all the organizations level, translating on the way what the CEO "really" meant. The real-time Enterprise is structured around mission-critical, real-time decision centers. These centers get an event, to which they immediately react. The model used is no longer "chain of command", but rather "sense-and-respond". That been said, it is clear that hierarchies are no longer relevant; moreover, they are a potential obstacle for spontaneous, on-the-spot reaction.
Nevertheless, the managers of the past are critical for the organization of the future. They are not redundant. Like their organization, they are transformed into new kind of roles.
Team Leaders – The Services Engineers
The team leader's new role has two facets: technical and instructive.
The team leader technical role is to be a chief architect, designer and engineer of the services of his/her domain of expertise. She should decide how the service would be implemented (the checklist…), how it would be automated and so forth. Along with this technical responsibility, comes an instructive one. The team leaders of the past become the gurus and the role models of the present. They teach, instruct, assist and mentor newcomers as well as other infra team members. Their role is to ameliorate the general purpose nature of each employee.
Department Managers – The Strategic Thinkers
The department managers become members in a new strategy sub-group. The strategy group is the ruling elite. They decide which services the infra group will provide to their customers; they design, add and optimize the functions of the I/O hub. Differently put, they define how the group as a whole should function.
They have multiple inputs for their endless organizational design: feedback from the customers; feedback from the infra group employees; statistics from the I/O hub and, of course, new technologies from the outside. All are combined to form the always evolving strategy of the group.
If this reminds you of Plato's Republic - well, I'd say it's an adequate association. Productive Workers [general-purpose resources], Protective Warriors [ex-team leaders] and Governing Philosophers Kings [ex-department managers] - are the three classes in Plato's Republic. No wonder many universities around the world started promoting a new kind of studies, the "Philosophy of Technology", using the following slogan: "Should Your Next CEO Be a Philosopher?"
Hmm, I think I'll have a glimpse on that Republic book.
Organizational Architecture Wrap-up
1. I/O hub
Requirements management, customer relationship management, internal PM, task management, resources allocation, and quality control
2. Strategy group (ex dept managers)
Which services, overall processes and procedures, new technologies
3. Experts Group (ex team leaders)
Designing and leading the development of the various Services, as well as being role models and mentors for the other employees.
Human, general-purpose resources executing the services
In the flat, ESDR real-time Enterprise, Managers are no longer managing (neither people nor projects); rather they become strategic thought leaders. As noble as this transformation might be, managers usually don't buy it.
The public image of the successful manager is almost always quantitative: how many employees do you have? How many projects do you manage? How big is your… budget?
Any CTO who is not managing (a considerable amount of) people is doomed to have a lower organizational image than his/her colleagues (and I recently heard that venture capitalists are nicknaming the CTO co-founder: "The Pizza Guy". Ask your VC friend for an explanation…).
So managers are automatically reluctant whenever it comes to renouncing on power (and indeed, why should they?). But there's another problem besides ego: not every manager wants or is capable of being a strategic thinker. So to make a (very) long story short – managers are the biggest challenge faced by the new organization. All the other problems that you might encounter in the transformation, such as processes which are not optimized; services suffering from poor quality; resources that are wrongly allocated etc. – all that is normal and gets better over time. People's mindset, on the other hand, is really hard to change.