It is common these days, in a talk about this or that ‘technology’ to say ‘of course it’s not really about the technology, it’s about the people and the process.’ The ‘people and process’ mantra has been said so many times that it has achieved motherhood and apple pie status. How could it be any other way?
P ’n P’
Well let me start by observing that if I call a plumber to fix a tap, the last thing I want to get into is ‘people and process.’ In fact if ‘P ’n P’ or virtually any form of discourse arises during the intervention, it is likely a sign that things are going wrong. The plumber (if you can get one!) is performing a nicely encapsulated service of a near algorithmic nature. Tap dripping -> call plumber -> tap fixed.
SOA
Until now I assumed that service-oriented architecture was more about the encapsulated ‘plumber’ service than ‘P ’n P.’ I mean, the ‘services’ in SOA are web services, right? And these are SOAP, REST, HTTP whatever that are carrying unambiguous messages and completely qualified data with context and all that good stuff.
Carter
Well yes and no—according to IBM SOA evangelist Sandy Carter. In a keynote to the Object Management Group meeting in Burlingame, CA last month Carter asked what was standing in the way of SOA deployment. An IBM survey found that the main lacuna was nit IT but business skills—that the shortage was of ‘enterprise architects’ not technologists.
T-shaped
Seemingly the N° 1 requirement for an SOA project is a combination of skill sets to ‘articulate and communicate’ across business and IT. This requires a ‘T-Shaped person’ with a skill set that enables them to identify a business service and communicate it to the developers. To achieve this, Carter advocates a ‘mini MBA’ course for IT Grads and IBM has initiated a range of initiatives to cross the gap and develop the ‘T-shapers.’
Wrong?
Now while there is nothing wrong with this, it did give me some cause for reflection. On the one hand, communicating the business problem to the programmer has been an ‘issue’ since the dawn of computing. On the other hand, the more T-shaped people you have running around doing the ‘P ’n P’ stuff, the more you run the risk of your project suffering from some form of paralysis by analysis. I really didn’t see what SOA had to do with the MBA folks at all.
What is SOA anyhow?
I consulted the Wikipedia oracle for a ruling. Like all oracles, Wikipedia provides answers to suit all. On the one hand, SOA is about architecting ‘intrinsically unassociated units of functionality, which have no calls to each other embedded in them’ in other words, ‘call the plumber.’ On the other hand, the article specifically refers to XML, WSDL and SOAP—which points to a fairly low level skill set.
Which SOA?
So is SOA about high level architecture and design? Or is it about low level web services? If it is about the first, then I would submit that it is a matter of faith that the ‘services’ approach will improve on the three tier architecture, on business objects or any other past paradigms. If it is about the latter, then at least there is a chance of solving the interoperability issues that plagued previous generations of IT silver bullets.
Selling SOA
Without being too cynical, one can see the push for SOA as an object lesson in IT marketing. First get the developers hooked on some new coding paradigm—SOAP, .NET—whatever. Then heat up the rarified air in the boardroom with talk of SOA as a new business paradigm. So when the top brass meets a coder at the coffee machine—they can play buzzword bingo and give each other warm feelings. SOA near and yet SOA far!
Pai
In our interview with Schlumberger’s Satish Pai (page 3 of this issue) we discussed the relative under-representation of the process control community in the ‘digital oilfield.’ Pai also stated that the downstream is ahead of upstream in the automation stakes. This was somewhat comforting as Oil IT Journal has been pushing the boat out in the direction of engineering and process control for some time now.
BP chemicals
In this context, I would encourage you to read the latest issue of BP’s Frontiers magazine* (summarized on page 12 of this issue). This describes in detail how BP optimizes its chemicals operations with a top down hierarchical control system operating at three different granularities and time scales.
Command and control
I know it sounds crazy, but I can’t help trying to squeeze a pithy conclusion by contrasting BP’s ‘command and control’ with the notion that we should train the MBAs in SOA. On the one hand, as a ‘renaissance man’ myself, I am all in favor of more freedom and interchange as making for a more stimulating workplace. But are we really going to teach the MBAs engineering, then SOA then SOAP?
Data management
I think the answer is probably yes to a degree. At least it would be a good idea to train engineers in architectural principles—but with an emphasis on data management rather than on services. A little knowledge of plumbing is after all good for us all.
ExxonMobil
I’m not sure that was very pithy so I’ll try again. Contrast ‘command and control’ with ‘renaissance persons.’ Now ask yourselves—which major oil company’s organization lies on the command and control end of the spectrum? And which ‘Irving-based behemoth has just set new ceilings for annual and quarterly profits ever earned by a US company?**’ I REST my CASE.
** Houston Chronicle.
© Oil IT Journal - all rights reserved.