The complex nature of business processes...
A couple of days ago I came across an intriguing post titled "
Fear, Greed and Social Software" on Many2Many, a pretty thought-provoking blog from Corante. Some interesting thoughts, but one point in particular caught my eye. Ross Mayfield points to "The Only Sustainable Edge":
'In the one business strategy book you must read this year, The Only Sustainable Edge, by John Seely Brown and John Hagel, the authors not only argue that innovation is the only sustainable edge, but that collaboration underpins innovation itself. [...] the readers of this blog will be interested in this. "95% of IT expenditure in companies supports business processes. Almost nothing goes into the social fabric." Meanwhile, the vast majority of what workers actually do is handling exceptions to process, what you could call the domain of business practice.'There appears to be some dangerous thinking in here, of the "if all you have is a hammer, anything looks like a nail" type. I'm not sure if it's a misunderstanding within "The Only Sustainable Edge" or by Ross Mayfield, but it sounds dangerously like an assumption that "social fabric" - which is an enabler of collaboration within a business - is somehow not related to business processes.
Business processes and "social fabric" within enterprises are certainly disconnected today - but that's the fault of the technology we have; it's nothing to do with the nature of business processes. Business processes are rich, collaborative, often unpredictable and organic. It's just that the shadow that they cast onto IT - the systems that we have built to automate parts of business processes - is highly structured and often rigid.
It's dangerous to look at the shadow that business processes cast onto IT systems today, and assume that this is what business processes really look like. Because then we all miss the real challenge of enterprise use of IT in the next five years: harnessing all kinds of information management and communication technologies, and blending them in ways that truly provide structured support for business processes as they really are.
Oracle's (con)Fusion Middleware?
A bit belatedly, I thought it would be worthwhile to add a different perspective to recent reporting around Oracle's rebranding of its "bag of middleware". For example,
Joe McKendrick at ZDNet likens the new Oracle Fusion Middleware brand to IBM's
Websphere.
But it's more subtle than that. The truth is that Oracle's intent is to create something much closer to SAP's
NetWeaver - a platform which helps Oracle convince customers that its sprawling set of packaged business applications will eventually work seamlessly together; while at the same time making customers less likely to look to a third party for application and service integration technology.
Meanwhile, SAP is taking it to the next level with its Enterprise Services Architecture (ESA) and Business Process Platform. This week saw SAP announce a slew of partnerships, with the likes of Adobe, Cisco, CA, EMC, Intel, Macromedia, Mercury, Microsoft, Symantec and Veritas around ESA...
Microsoft and Sun mark one year of collaboration
On Friday 13 May, Sun and Microsoft provided the second update on their year-long collaboration since the announcement of
their landmark 10-year cooperation agreement in April 2004. In contrast to the last update in December, Scott McNealy and Steve Ballmer – amidst much on-stage bonhomie – were in a position to discuss some tangible results from their companies’ cooperation. The bulk of the update focussed on Web SSO (single sign-on), including an interoperability demonstration, but they also highlighted progress with management interoperability (discussed in more detail in our report
Microsoft bids for role as enterprise management player) based on
WS-Management, and hinted at future plans in areas such as storage management.
Continued demonstrations of progress, which are meaningful to customers and partners alike, are important, since the rapprochement between the two companies is critical for both - although Sun's need is more pressing than Microsoft's. For Sun, interoperability with key Microsoft technologies is an absolute requirement for it continuing to be seen as a viable supplier; whereas for Microsoft it's more a matter of credibility which will make it much easier for it to be seen as a serious provider of enterprise-class software, as well as providing it with some ammunition in its interoperability battles with regulators in the US and Europe.
It's easy to infer from the Sun-Microsoft announcements, that both companies see IBM a common enemy; and that their interoperability drive is a means to push their technologies to the top of the tree when it comes to middleware for the new generation of open, service-based business software. But the truth is more sophisticated than that. For while Sun is clearly threatened by IBM from a large number of directions - not least, in IBM's promotion of Linux as a Solaris substitute - Microsoft's relationship with IBM is (for the moment at least) a collaborative and productive one. The truth is that Sun and Microsoft together need to present such a front to the industry, because a great number of the services and integration partners that they both share, are so implacably pitted against IBM Global Services and Business Consulting Services. To emphasise this point, senior executives from Accenture, EDS and NEC joined McNealy and Ballmer to praise the collaboration.
To drive their collaboration forward, the two companies set up a small "Technology Advisory Council" consisting of ten, large mutual customers. Identity management was the top-rated issue of this group. What was announced today, though, is really only the start of what these and other customers will want. Web SSO is nice but in reality it's only likely to be interesting in a minority of situations. In reality application-to-application identity federation is really important; as is single sign-on for non-Web applications. Furthermore, the interoperability protocols announced (
Web Single Sign-On Metadata Exchange - Web SSO MEX - Protocol and Web Single Sign-On Interoperability Profile - Web SSO Interop Profile) provide a bridge between the Microsoft (and IBM)-backed
WS-Federation specification and the Liberty Alliance’s
Liberty ID-FF, which wouldn’t be necessary if Microsoft were to follow the lead of IBM and commit to the Liberty Alliance.
In addition to the work on browser-based Web SSO, Sun announced that it has licensed Microsoft’s Remote Desktop Protocol which it plans to implement in its Sun Ray thin client product to allow them to access Windows Terminal Services running on Windows Server 2003. One of the obvious targets for Sun Ray are the low-spec PCs running Windows NT Workstation, 95 and 98 which still exist in enterprises of all sizes. It is somewhat of an unfortunate coincidence (or perhaps not) that Microsoft chose this week to start talking in public about its plans for Eiger, the code name for a ‘lean’ – not thin – client version of Windows XP designed – you guessed it – to run Windows Terminal Services and browser-based applications on low-spec PCs.
So, with one year down and nine to go, Sun and Microsoft are beginning to deliver. The somewhat tardy progress to date has been put down to ‘getting to know you’ teething problems, particularly amongst sceptical engineers. That excuse will no longer hold water and the two companies are going to have to work hard to provide truly business-meaningful interoperability, whilst remaining – as McNealy and Ballmer were both at pains to point out – ardent competitors.
IBM's acqusition of Gluecode: it's about more than open source
On May 10, IBM announced what it referred to as a “significant software acquisition” – that of an 18 person company founded less than two years ago! Following so soon after the closure of the $1.1 billion acquisition of Ascential, one could be forgiven for questioning the significance. With the benefit of two days in which to ponder, I can see that IBM has a point – and it’s only indirectly related to open source.
The acquisition of Gluecode adds a lightweight, no-cost Apache-based stack (application server, JSP and servlet container, database and portal framework) to meet the needs of the enterprise (and ISV for that matter) developer community, for whom WebSphere is a hammer to crack the proverbial nut. This was also the motivation for the company’s
agreement with Zend Technologies to create ‘Zend Core for IBM’, designed to make it easier for developers to build PHP applications which integrate with IBM’s Cloudscape and DB2 Universal Database. IBM is now in a position to offer enterprise developers a viable alternative to the likes of
JBoss and
JOnAS, both of which have been gaining traction in enterprise development shops. It’s also one in the eye for the likes of HP and Novell, both of whom have cosied up to JBoss.
IBM also gains a new revenue model – at least as far as the WebSphere brand is concerned: subscription-based support and services. The likely revenue pales into insignificance when compared to the $3.6 billion quarterly software revenues reported in April but it provides IBM with an opportunity to test a subscription-based model with its enterprise customers.
The acquisition also bolsters IBM’s strategy for tackling the SMB segment. Whilst it already has its Express offerings, these are primarily oriented towards the ‘M’. The Gluecode stack has the cost and acquisition attributes i.e. free and downloadable, which are attractive to the ‘S’. Of course, there’s no point being able to download it for free if you can’t use it. Gluecode, as IBM freely admits, requires ‘deep Java skills’, and these are going to be in short supply in the smallest of small businesses. However, a good number of sub-Express-sized companies do possess dedicated IT staff who, with a little paid for support from IBM, could turn their hand to some Java development. Not forgetting of course that IBM’s channel partners can lend a hand too. IBM will, of course, have to be careful to ensure that it does not compromise its WebSphere Application Server – Express revenues.
Whilst this acquisition does give IBM’s PR and marketing machine the opportunity to expound on the company’s open source strategy and commitment to the community, it has more to do with extending the footprint of the WebSphere brand in the enterprise and SMB segments.
A note re: the IBM-Lawson Software tie-up: just remember San Francisco
A cautionary note to anyone getting carried away thinking about the potential ramifications of the tie-up between IBM and Lawson Software (mid-market vendor of packaged application software) - Lawson was one of the high-profile vendors which signed up to support IBM's
San Francisco project, which started with great fanfare in 1994. San Francisco was an attempt by IBM to create a Java framework for enterprise applications which would be OEMed by ISVs, and which could also be procured and built on by in-house IT departments.
Nothing wrong with that, in principle - of course, what is Microsoft's
MBF if not something extraordinarily similar? ...except that IBM was stunningly ahead of its time. Anecdotal evidence at the time indicated that the whole thing ran like a three-legged dog. The project and slid quietly into obscurity at the end of the '90s.
The head of the San Francisco project within IBM? One Danny Sabbah...now
extolling the virtues of SOA, which
Lawson is touting as the architectural foundation of its re-engineering exercise...
Gupta gets it – now can CA deliver?
It seems that all that fresh blood at CA is creating some really interesting stirrings. At yesterday’s
Interop Data Management and Compliance Conference, CA’s CTO, Yogesh Gupta, talked about the importance of putting business processes at the heart of IT thinking in order to improve IT-business alignment.
In particular he talked about "determining how the business process model interacts with IT services". Our experience is that this is absolutely the right way to go about thinking about IT-business alignment – with a clear and shared understanding of business processes, underpinned by a catalogue of managed IT services, at the heart of things. What’s great, is that Yogesh was talking about "IT services" from the perspective of operational management, rather than from the perspective of software development. Bravo!
This is really important. SOA (as commonly discussed today) is all about software development – and this is a real problem. It’s only when you can pull the different perspectives of IT services together (development, deployment, operations, support & change) that you really have an understanding of what service-orientation is actually about, and how it might contribute to IT-business alignment. It’s a shameless plug I know, but has Yogesh been sneaking a peek at
our stuff?
Of course it’s one thing for a CTO to be (a) ahead of the curve and (b) able to communicate effectively. It’s another thing for the company as a whole to turn this thinking into a coherent story that threads through its product developments, services offerings and so on. We watch with interest...
OASIS SOA Reference Model - a positive start but limited in scope
On Monday 3rd May, the standards consortium OASIS
announced the formation of a committee to develop a core reference model designed to “guide and foster the creation of specific, service-oriented architectures (SOA)”. When I first read the announcement I was encouraged on a number of fronts. Firstly, the formation of the committee recognises, as our own research shows, that organisations are increasingly confused by the seemingly endemic and varied use of the term SOA in vendor propositions. Secondly, and as a consequence of the first point, the initial membership of the committee includes a variety of users of technology, such as Boeing, General Motors and VISA, in contrast to the vast majority of standards-setting bodies (the Liberty Alliance is a notable and successful exception).
As I dug a little deeper, however, my enthusiasm waned. The absence of the likes of BEA, IBM, Microsoft, Oracle and SAP from the roll call of members is disappointing since these are the vendors that users are likely to turn to first as they embark on their SOA initiatives. They are also, as a result, a potentially valuable source of first-hand experience. I can’t say I am surprised by their absence, given that their insight into SOA best practice is a valuable resource in their pursuit of new business opportunities. I hope, just as we have seen with the Liberty Alliance, that the participation of their customers and prospects will help to bring them to the table.
I was more concerned, however, with the implication of some of the language used in the announcement - “the new OASIS SOA Reference Model (SOA-RM) Technical Committee will promote the continued development of multiple SOAs” and “The reference model … will be an abstract, designed to be used as a tool by software and enterprise architects developing specific SOAs”. It appears that the foundation of the committee is based on the same train of thought which permeates much of the current dialogue surrounding SOA: that SOA is something that you implement. This predominantly development-centric perspective on SOA is, in our opinion, too simplistic and the cause of the much of the confusion which the committee has been established to reduce.
We believe, as we outline in our report
“SOA: handle with care”, that SOA is something that you do not something that you implement. It is an approach through which IT services are managed throughout their lifecycle and delivered in line with business priorities. The development-centric perspective on SOA focuses on the issues faced by software developers in building and integrating web services but this is only part of the story. An SOA initiative must also take account of the IT service perspectives of the other key stakeholders – IT operations and the business groups that control the purse strings – to provide a more complete picture of “service-oriented IT”.
Don’t get me wrong. I remain positive about the SOA-RM and applaud the committee founders for shifting the focus from, some would argue, intangible and highly technical standards specifications to more meaningful advice and guidance. However, the committee needs to extend its scope to consider not only the IT services that automate aspects of business functions and are the primary concern of developers but also the infrastructure services that provide that platform that underpin those services and the lifecycle services that are responsible for the design, implementation, operation and alteration of both business function and infrastructure services.
