 |
 |
BPM isn't yet "the killer app for SOA"
As part of our BPM Continuous Advisory Service, we're carrying out twice-yearly research studies which capture information about the state of maturity and practice of BPM in European businesses. We've finally finished analysing the results of our first study, and published the report. One of the most interesting things for me in processing all the findings from the study was that for now at least, making too simplistic a connection between BPM and SOA looks like being a risky thing to do. Where BPM and SOA initiatives exist in organisations today, all the signs point to them being conducted in completely separate worlds, by completely separate teams with wildly differing sets of assumptions and expectations. We've highlighted other key findings of the study over on our BPM blog, which is a key element of our BPM service but is freely accessible by anyone. Labels: BPM, MWD, SOA
Businesses aren't machines, and enterprise architecture can't make them so
Via Service Oriented Enterprise, I recently picked up an Infoworld blog post by SOA journeyman David Linthicum, where he makes a couple of very strange points about SOA and ESBs. It may be, of course, that the post is pure link bait: certainly, David appears to have said some relatively sane things in the past, so that might be it. If it is link bait, I'm going to fall for it now. In his piece David quotes a representative from iTKO, who repeats the now well-understood insight that in some large organisations, there's a challenge that arises because different groups with SOA initiatives find themselves having to integrate different ESBs in order to pull together implementations for cross-silo scenarios. He then goes on to comment (I?ve taken the liberty of extracting elements of his piece below):
First, if there is indeed 'enterprise architecture' and an 'enterprise architect' then the different divisions should not be using different ESBs, or even an ESB for that matter... Second, considering that my first point is correct (which it is), why the heck are you attempting to integrate these integration engines when they should perhaps be displaced altogether. Because, call me crazy again, that would be cheaper... just to be clear, you determine your requirements, and then the solutions patterns, and then the technology. The most charitable explanation I can come up with for David's position is that he believes passionately in the transformational power of enterprise architecture. The problem with this perspective is that even where EA is highly effective (and in many places it isn't), it can at best only be one of many forces shaping the way that IT evolves to support changing business conditions and requirements, and each force has its own vector. Some forces, like a good EA team, try and combine business and technology focus, and promote the value of global optimisations, good practice and standardisation. But most of the most powerful forces are business forces, and in 99.99% of organisations, their power, when something really big and important happens, will trump any righteous splutterings emanating from IT departments. As any experienced IT staffer who's been on the sharp end of a big business merger or acquisition, or even a radical change of leadership, will tell you, businesses don't act like machines that EAs can simply steer so that they tend towards technology optimisation. In fact, it's the opposite: business change forces (new competitors, new product launches, new market launches, new regulations, mergers and acquisitions, and so on) will always drive entropy, tending to push IT estates towards chaos. The best value an EA team can really provide in this environment is to help the IT organisation to absorb these changes with as little stress as possible, and drive consistent, planned responses. Still, there's always been a vocal (and quite often technically brilliant) part of the IT industry that seems to misunderstand this, and persists in maintaining that once people see beautiful models, they'll modify their behaviour to enable the models to be made real. They see businesses as deterministic machines that can be algorithmically decomposed, analysed, predicted, and shaped. I can only think that David is one of these people. Unfortunately, no matter how clever your EA team might be, no amount of architecture astronautics can make businesses change their nature. Labels: EA, ESB, inside-out IT, SOA
Which comes first: process or service? Part 2
The question of how to combine BPM and SOA came up a lot here at TIBCO's TUCON user event - and, a little disappointingly, the standard response seems to typically revolve around reinventing the three-tier architecture of the 1990s, just with more scope and scale. I pointed out in the previous part of this post a few ways in which that perspective is too short-sighted. It's OK to view BPM and SOA as both essentially technology approaches to building and integrating applications, but this is a perspective that misses a big part of the potential business value of the combination. What we're starting to see, though, in a few advanced organisations, is how top-down, business-driven approaches to service orientation and business process thinking can combine with bottom-up, technology-driven approaches. The model that we see links an approach to business architecture that leans on the concepts of process and service to describe business fundamentals, with an approach to technology architecture that uses the same concept to describe the operation of automated systems. The same concepts are used at multiple levels of abstraction and composition/decomposition, so the link is seamless. To make this link, the concepts of process and service are united through a third concept: outcome. The middle section of the diagram below, which outlines a process- and service-oriented view of business architecture, calls this out.  This is how it lays out: - Outcomes are desired results. An outcome at the highest level is likely to be something concerned with the core value of the organisation, financial performance, etc. At this level, outcomes might link very straightforwardly to mission statements. At lower levels outcomes are going to be concerned with operational results - for example "product is delivered".
- Services are commitments to achieve outcomes.
- Processes are the methods through which outcomes are achieved.
One of the realisations that should come when you think about this approach is that service-oriented thinking can "drive" process thinking - but not only because technical process implementations can be wrapped with technical service interfaces, as I mentioned in the last post. More importantly, service-oriented thinking should drive process work because when you define business services (commitments to achieve outcomes) you're actually providing business context that shapes the KPIs and goals that you need to set for processes in BPM initiatives. Another way to explain this aspect of service orientation is like this: when you model a process, and define a KPI and a target for that KPI, you're actually modelling aspects of a service "wrapper" for the process, as well as the process. You're defining what the commitment to achieve the outcome looks like, as well as the method you'll use to achieve the outcome. It's only when you start to think in terms of outcomes (and then services and processes) that this becomes clear, though. There are other ways in which SOA and BPM can be intelligently combined to add value to both that aren't just about simplistic views of integration (and I'll try and get to some of those in future posts, watch this space) - but I think this is one of the most important. It's important because it helps people get their heads around a way of linking business architecture work with technical architecture work - with one consistent set of concepts. To date, there haven't been many ways to do this, and our research suggests that few organisations manage to make the link effectively today. To come back to the post title: when you start to think about outcomes as a core concept in business and technology architecture, it becomes clear that it's not accurate to say either that services come first, or processes come first: the truth is that *outcomes* come first, and services and processes are two sides of the same coin in achieving the right results. Labels: BPM, EA, SOA
Which comes first: process or service? Part 1
Over the years I've been helping to run MWD I've been to quite a few events, talked to many enterprise IT folks and talked to many tech vendors, too - and one of the topics that comes up most often is the relationship between BPM and SOA. There's been a bit of a run on the topic in the blogosphere lately. First, I was alerted to this post on CIO.com via the EDS fellows' blog in a post called SOA is a Business Process Architecture. At around the same time, I read The Problem with Process by Nick Malik (always good to read). Too often, in presentations and papers, I see diagrams that replicate the old three-tier architecture of the '90s, but with a twist: instead of user interface, business logic and data access layers, now I keep seeing portal, BPM and SOA layers. Portals provide user interaction, and invoke processes; processes invoke services. Job done. Looking at BPM and SOA purely in this way is short-sighted, disingenuous and dangerous. It looks at both initiatives through a very focused lens, and essentially says "BPM and SOA are about building and integrating applications". Not your father's applications I'll grant, but applications nonetheless - things with hard boundaries that have little awareness of other systems or resources that might exist, and little conceptual relationship to broader architectural or business considerations. The first, and most obvious, point to make that blows this kind of picture apart is that it's mind-numbingly straightforward to wrap a process (or at least the initial invocation of a process) as a service. So *now* what's "on top" - process or service? This realisation has led to more enlightened commentators advocating that organisations consider processes and services more like a lasagne, with alternating layers of the two concepts. Services expose processes, processes call services, etc etc ad infinitum. However even here we're only part way to the real answer, because this view also stems from seeing both BPM and SOA primarily from a "bottom up", software development- and integration-centric perspective. Of course, many people refute a view like this, and point out that "BPM is a business management approach, and SOA is a technology architecture approach - you can't lump them together so easily". In other (very simplistic) words BPM is a top-down, business-driven initiative, whereas SOA is a bottom-up, technology-driven initiative. The two articles I've linked to above are great because they start to take a deeper look at the architectural and conceptual relationship between service and process. Both EDS Fellow Fred Cummins and Nick Malik start to pick away at the simplistic views that seem to hold sway in the minds of many at the moment. Neither quite take the argument as far as they might, though. Through our industry research (for our book as well as our various free reports and consulting gigs), we've come to see that the value of both BPM and SOA comes from considering them neither purely as bottom-up initiatives focused on improving the development / integration of applications and resources, nor as top-down initiatives focused on exploring and elaborating business architecture. We already have a champion in the case of "top-down SOA" - the OASIS SOA Adoption Blueprints team. The real insights come, I think, when you see how top-down *and* bottom-up perspectives of service-orientation *and* process-orientation can all come together in a more holistic view of business and technology architecture. I'll expand on what such a view entails in a Part 2 of this post, in the next few days. Labels: BPM, EA, SOA
HP tightens up its SOA governance proposition
HP yesterday announced long-awaited (at least as far as we are concerned) enhancements to its SOA software and services, which see the company beginning to realise the potential of its acquisition of Systinet (via Mercury) when it comes to SOA governance. Back in March, the other Neil highlighted that lifecycle management is one of the four key elements of an SOA functionality pyramid and is: all about supporting development, integration and operations teams in linking their efforts to ensure that the consumer service experience is high-quality and consistent under potentially unpredictable circumstances. Typically the foundation of this capability is some kind of registry/repository, but ideally tools go further than this - firstly by helping to automate team workflows for implementing quality controls at design time; and secondly by helping to translate design intentions relating to operational SLAs into runtime policies which are tied into the infrastructure. HP is attempting to go that bit further by more tightly integrating the registry/respository capabilities it acquired with Systinet to the policy-based management and monitoring capabilities of its SOA Manager product. Whilst HP also brings other valuable functionality to fill out the SOA pyramid, including business process monitoring (HP Process Insight), security and identity management (HP Select Access) and synthetic transaction monitoring and reporting (HP Business Availability Center) it does not - and nor would it claim to - have everything. Enter the Governance Interoperability Framework (GIF) it inherited from Systinet. The GIF is designed to facilitate information exchange with the Systinet Registry and Repository allowing third parties to integrate relevant technologies, such as policy enforcement and service orchestration, with the SOA lifecycle management capabilities. As well as announcing 10 new GIF partners, HP is also publishing the GIF specifications. Integration is not totally reliant on GIF though. Systinet's registry is also embedded in the SOA infrastructure offerings from the likes of BEA, Oracle and TIBCO, which makes HP an obvious potential source of broader SOA lifecycle management functionality for their customers. The company is not such an obvious choice for customers of IBM and Software AG who are building out their own capabilities. SOA platforms do not begin and end with BEA, IBM, Oracle, Software AG and TIBCO though. There are other choices: Microsoft, Progress, Red Hat and SAP etc. Not forgetting of course that organisations will be acquiring service oriented solutions as part of business applications. What's the story there? There are two. The first is GIF. The second is the HP SOA Registry Foundation that also formed part of yesterday's announcement and which the company describes as a new software product expressly designed for independent software vendors. HP SOA Registry Foundation is a powerful, standards-based way to publish, categorize and discover SOA services and artifacts. This new product can be easily embedded with packaged applications and distributed solutions. In other words, it's an OEM-specific version of the registry designed to allow HP to replicate the BEA, Oracle and TIBCO agreements. Coupled with the HP's services capabilities, these announcements should mean that HP is able to exploit its systems management heritage and installed base to position itself as a credible SOA lifecycle management provider to organisations moving beyond project-level SOA initiatives - and to the software vendors that are helping them on that journey. Labels: governance, HP, service, SOA, UDDI
SOA's five benefits in one picture
In recent discussions with one customer, I ended up drawing a series of little pictures to try and summarise the five potential benefits that can come from pursuing SOA. It seemed to work for them, so I thought I'd reproduce it here and see what our readers think. In order to test the old adage that a picture speaks 1,000 words, I'm not going to write a whole lot to explain what the diagram is showing: if it's a good diagram then you should be able to work that out pretty quickly. Of course, if I get an avalanche of comments asking for an explanation then (1) of course, I'll post one; and (2) it's not as cute a diagram as I thought it was! UPDATE: I managed to cut off the bottom of the original image when I uploaded it, so here's another one.  Labels: SOA
Please don't hire a VP of SOA
This might sound like an odd title for a post, but I was prompted by this ZapThink ZapFlash, via the ever-watchful Todd Biske. The ZapThink note starts off talking about the challenges in SOA adoption that come from organisational issues - specifically, challenges that arise from situations where tactical decisions continue to trump strategic decisions. All these are good points well made (FWIW, when trying to educate people about the importance of enterprise architecture, governance, BPM and SOA, we talk about the strategic importance of global vs local business optimisations). However the note all goes wrong when it goes on to say: Among the various approaches organizations take to overcome such obstacles, one technique is increasing dramatically in popularity: bringing on board a new executive responsible for the enterprise's SOA initiatives. Really? I haven't seen that. If some organisations (maybe US based ones?) are doing this, I hope they're more focused on business transformation than on IT implementation - and that SOA isn't in their job title. The note then goes on to suggest some ideal characteristics for such an executive: The ideal candidate will first and foremost be a business process guru who also has broad experience in IT. Must have a background in architecture and ten-plus years in increasingly senior management roles. Must be able to communicate to both business and technical audiences. The successful candidate will be part team builder, part evangelist, and part bean counter. Although it's slightly off the topic of this post, I wonder how many people fitting this description are out there? If SOA success relies on you hiring someone with all these capabilities, then I think we're going to see a hell of a lot of failures. This is where I get seriously worried though: This position reports directly to the CIO with dotted line responsibility to the COO, and will be responsible for a seven-figure annual budget... job responsibilities include:- Provide executive-level management leadership to all architecture efforts across the enterprise. The directors of Business Architecture, Enterprise Architecture, Technical Architecture, Data Architecture, and Network Architecture will all be your direct reports.
- Drive all Business Process Management (BPM) initiatives enterprisewide. Coordinate with process specialists across all lines of business, and drive architectural approaches to business process.
Ummmm... so this role reports to the CIO, but drives all BPM efforts across the company? Even though the note says "even though the VP of SOA reports to the CIO, the role is primarily a business role" this is pure fantasy. Unless you're in a small-to-medium business it's just not practical to make this happen. Think of a concrete example of a process transformation - something related to CRM. There's a wealth of salutory tales out there about the folly of driving CRM initiatives (which are process improvement/transformation initiatives) from within IT: CRM initiatives need to be owned and driven by the business. Extrapolating out to process improvement/transformation more broadly, even if transformation of some process areas isn't in the same league as that involved in CRM (and you'd have to argue hard to convince me of that) then I'd still argue that business leaders have to share ownership of process improvement and transformation initiatives. Real BPM cannot be driven by someone reporting to your average CIO - not even by a $200k-a-year uber-architect-cum-process-guru who's equally happy wearing patent leather shoes or pizza-stained trainers. Of course there is a need to bring people together to push through significant IT and business transformations, such as those required to make the most of the promise of SOA and BPM initiatives. I would wholeheartedly back ZapThink and others in that. But in the real world - particularly in large organisations - people who drive these change programs aren't able to directly push everything, as ZapThink seems to be advocating: they have to be influencers and coordinators first and foremost. Think of an enterprise architect you know. If they're successful, chances are one of their key skills is in how they influence others' behaviour and get different stakeholders working together. Even if you believe that one role can drive all this - especially from within the IT organisation - then your VP of SOA will be a transitory role. If your SOA initiative succeeds in its mission, then SOA becomes part of the furniture, and when that happens, roles like this one melt into the responsibilities of other, "business-as-usual" roles. If your SOA initiative doesn't succeed, then SOA is seen as yet another over-hyped industry silver bullet - and your $200k-plus hire is now seen as an expensive mistake. Labels: BPM, SOA, toddbiske
Who do you put in a Centre of Excellence?
I've lost count of the number of times I've seen throwaway comments exhorting companies to "create a centre of excellence (CoE" (mostly, for initiatives like SOA or BPM). Vendor / pundit / analyst / journalist: "Having trouble? Establish a centre of excellence!" Customer: "Oh, that's OK then, I'll do that." But let's take a deeper look. Quite aside from the role that one of these beasts plays (something I'll attack in a future post), what does a best practice CoE look like? From what I've seen out there in real-world implementations of SOA and BPM initiatives, I suspect that the best results come from having a good mix of responsibilities / personalities in the group. Something like an even distribution across this matrix of perspectives:  Although it's tempting to staff a CoE with good dependable technical people that you understand, you need a good mix of business-focused types and technology-focused types, because those business-focused types will help keep expectations practical, and help keep business people from outside the CoE engaged and willing to help. And it's vital to get a good mix of practical and visionary focus, because rolling out new concepts and approaches to delivering IT capabilities requires both "selling" and getting things done. That's my view. What do you think? Labels: BPM, governance, SOA
Oracle proposes to buy BEA
Oracle today confirmedthat it delivered a letter to the Board of Directors of BEA Systems, Inc. (NASDAQ: BEAS) on October 9 in which Oracle proposes to acquire BEA for $17.00 per share in cash. The $17.00 per share offer is a 25% premium over yesterday's closing price of $13.62.This acquisition has been long-discussed so I can't say I find the news particularly surprising, particularly with Carl Icahn recently upping his stake in the company. I think this just makes it more likely that Oracle's proposal will be accepted. This is primarily as a market share grab by Oracle. It does plug some gaps in the portfolio - particularly around business process management (based on BEA's Fuego acquisition), where Oracle only has basic BPEL web services orchestration; adds some telecoms vertical market capabilities to complement Oracle's vertical market push and the virtualisation work that BEA has done with the WebLogic Virtual Server Edition. Also, there's the opportunity for Oracle to tap into the healthy Tuxedo base. With a significant chunk of Oracle's profitability coming from maintenance, the revenue from BEA's customer base will suit its business far better than it did BEA which was suffering with its inability to grow license revenues. This is yet another example of the bigger specialist players getting squeezed out by the industry goliaths - IBM, Microsoft, Oracle, SAP - and the open source, smaller best-of-breed players. SAP's recent acquisition of Business Objects is another example (although that did plug a few more gaps). It leaves some of the other bigger specialist players - TIBCO, SoftwareAG (and to a lesser extent Progress and Red Hat) in an interesting position. On the one hand they will be more attractive, particularly for SOA and BPM, to customers looking for an application-independent infrastructure offering. On the other, though, taking market share for those customers from BEA is one thing: taking it from Oracle quite another. Ultimately, IBM is the big beneficiary in this regard. In summary, then, I see: the acquisition going ahead; BEA's customers looking worried as they see themselves with an application-dependent infrastructure stack; IBM looking happy at the prospect of providing those customers with an application-independent alternative; the likes of TIBCO and Software AG pondering their options; and SAP and Microsoft carrying on in there own sweet way. Labels: BEA, BPM, ibm, Microsoft, Oracle, Progress, Red Hat, SAP, SOA, Software AG, TIBCO
More big vs small thinking: SOA vs BPM
I was on the way back to the office from a briefing with BPM vendor Pegasystems yesterday, where we'd had an interesting discussion about the relative roles that BPM and SOA can play in business transformation for customers. We agreed that BPM, done right, is as much of a discipline that organisations can use to transform the way that they do business, as it is a technology (or set of technologies). What's more, we observed that many BPM initiatives revolve around making big changes to the way that organisations deal with customers, partners and suppliers - and creating organisations that are really focused around delivering real service to those other parties. Let's review that for a second: BPM thinking helps organisations get their houses in order so that they can deliver coherent and quality services (and not just disjointed experiences). So from a business perspective, it's BPM that delivers service-orientation! But wait - in IT we're saying that service-orientation comes from something called SOA. And in IT circles, there's a lot of discussion that positions BPM as if it's a layer of technology that sits on top of SOA technology. Kind of like we've just reinvented three-tier application design with BPM instead of business logic, and SOA instead of database access logic. This "application architecture" lens for BPM and SOA is all wrong. It's another example of small thinking. The more profitable way of thinking about the relationship between BPM and SOA is not to think of them as a stack of technologies: it's to think of BPM as being about "how" you do things and service-orientation being about "what" you do. Service definitions are definitions of commitments: they say what you will do, how well you can do it, and (possibly) how much it will cost you to use. Process definitions are definitions of work: they say how commitments will be fulfilled, by whom, and under what conditions. So, BPM and SOA are interlinked - but not because one adds value to the other or because one sits on top of the other: both ideas are two sides of the same "business and IT transformation" coin. If you do insist on thinking of the world in terms of stacks of technology tools or stacks of models or assets, think of SOA and BPM as alternating layers of concepts and practices. Services define "what" you will do at a given level; processes define "how" services will be delivered. Processes rely on foundation services to get some work done; those services in turn rely on processes of some kind. I'm sure not everyone will agree with this, but I do hope there's one thing we can all agree on - as Sinatra once sang: "this, I tell you brother: you can't have one without the other." Labels: architecture, BPM, Pegasystems, SOA
Early praise for SOA strategy planning tool
Just saw this great comment from Enterprise Architect blogger James McGovern. This site is incredibly useful. It was developed by MWD so you know it is of high quality. Thanks so much James - what an endorsement! If you want to get to grips with your competency levels in the context of SOA, and learn how you can improve them and plan a SOA strategy, visit http://www.itstrategyplans.com/soa. Labels: MWD, SOA, strategy planning
New SOA strategy planning tool - live from today
Today we're delighted to announce that our SOA strategy planning tool, hosted at www.itstrategyplans.com/soa, is now live. This is a new thing for us and if you're interested in SOA, we think you'll find it useful.  What we've launched is a comprehensive, interactive, and vendor-independent online tool that goes much further than IT vendors' own online SOA assessment tools - and crucially, there's nothing behind it that is going to steer you towards buying tools or technologies from a particular company.  You can use the tool, free of charge, to determine your levels of competence in six areas that are crucial to SOA success: concepts, strategy, architecture, organisation and people, governance, and technology and infrastructure. On top of that, you can quickly see how your levels of competence compare to average industry benchmark scores.  As I said above, access to these features costs nothing. If you want to know how your competence levels affect your SOA strategy and how you can reduce the costs and risks associated with SOA, then for a modest fee (normally £200 - but if you purchase before the end of September 2007, it's £130) you can gain access to premium features. With premium access you can generate personalised action planning reports that clearly lay out actions you need to take in order to improve your competency levels - as well as providing more detailed breakdowns of how you compare to the benchmark averages (across your industry, geography and company size). You can use premium access to generate as many reports as you like, whenever you like. So as your SOA programme progresses and you gain more experience and capability, you can revisit the tool and gain new insights. It's been a long, long road, and we (and our partner JEMM Research) have put in months of effort to get here since we started work on this project back in November 2006. This has been a major investment for us - so why have we done it? There are two reasons. Firstly, of course, we'll be delighted when people decide they want to buy premium access to the tool. That's easy. Just as importantly, though, we wanted to try and find new ways of learning about how companies are pursuing key IT initiatives. By building tools like this one and inviting people to use them to learn about their competence levels and how they can improve, we're also able to look at aggregated usage data from the tool to see how industries are grappling with SOA, and how the situation is changing over time. For a group of companies that talks so much about technology innovation, we've found that the IT industry analyst community is generally pretty slow at trying to use technology in new ways. As a small company we can perhaps make bolder moves more quickly - and that's what we're trying to do here. If we see success with this tool, we'll be launching more over time, focusing on different types of IT initiative. So - please check out the tool, give us your feedback, and let us know if there are other areas you think we should apply this approach to! Labels: MWD, SOA, strategy planning
Microsoft's Dynamic IT: it's a start
I have just returned from a couple of days in Orlando, where I attended a Microsoft Server and Tools Business analyst summit which coincided with the company's TechEd conference. The RedMonkers James and Coté did a great job of live blogging the event ( here, here, here, here, here and here) - and there was even some Twittering - but I needed the joys of a 9 hour transatlantic flight to collect my thoughts. The big news at TechEd and the focus of the analyst summit was Microsoft's Dynamic IT for the People-Ready Business (Dynamic IT) strategy, which the company describes as building on the company?s Dynamic Systems Initiative and ongoing Application Platform efforts to provide customers with the key areas of technical innovation necessary to make their IT and development organizations more strategic to the businessIn other words it's a framework which builds on a number of Microsoft's most significant, but historically largely disconnected, initiatives which is designed to help customers understand how they can be combined to increase the business value of IT. This is long overdue, for a couple of reasons. First, whilst Microsoft has used language in the past which implies linkage between the different initiatives and associated products, such as 'design for operations' for DSI and .NET, it's not always been clear how the implication becomes reality. For example, how do the System Center management tools exploit operational policy requirements defined in Visual Studio and how do those requirements map to policies defined in Windows Communication Foundation? Dynamic IT sets out to make the linkage explicit. Second, Microsoft has lacked a cross-company vision for enterprise IT (for want of a better term) within which to frame discussions with customers and around which it can rally the troops. I'm thinking here of things like IBM's On Demand, HP's Business Technology, Oracle's Fusion etc. There's People-Ready of course but I think that's about more than Enterprise IT. Dynamic IT provides Microsoft with a competitive alternative and one that is more reflective of current reality than future aspiration. There are four aspects to Dynamic IT where Microsoft plans to focus innovation: - unified and virtualized
- process-led, model-driven
- service-enabled
- user-focused
built on a federated, interoperable and secure foundation. Obviously, it's still very early days but I do think Microsoft has a lot of work to do if it's going to achieve what I believe it hopes to with Dynamic IT. For example, in his keynote when Bob Muglia talked about process-led, model-driven he discussed process-led in terms of the application lifecycle, BizTalk, Windows Workflow Foundation and Office Business Applications and model-driven in terms of System Center and IT management models (based on Service Modelling Language and the Common Model Library). What he didn't do was explain the relationship between the two. When describing service-enabled, he focussed on .NET, SOA, web services and software plus services, primarily from the bottom-up, developer perspective (consistent with Microsoft's initial foray into SOA) but failed to tie that into the end-to-end service lifecycle - Big SOA - and thus process-led, model-driven. (As an aside, I think Microsoft is also missing a trick when it comes to information and data as a service but that's for another day). As well as explaining the relationships between the different aspects of Dynamic IT, Microsoft also has to be very careful that it doesn't fall back into the trap of using it simply as a framework for categorising its products. Increasingly, the key concerns of the people it is trying to reach with Dynamic IT don't fall into neat product categories and Microsoft has struggled in the past to articulate the joined-up propositions required to address these concerns because of its focus on product stovepipes (as I discussed here). What I think Microsoft needs, as I explained during various meetings at the summit, are scenarios and associated case studies to bridge between the framework and the products and emphasise the linkage. This will also serve to highlight the importance of the three foundational aspects - federated, interoperable and secure - which might otherwise be lost and to tie into Core, Application Platform and Business Productivity Infrastructure Optimization roadmaps which Microsoft is using to help customers understand how they move forward from where they are today. For Microsoft's customers and potential customers Dynamic IT is a positive sign that company is beginning to recognise that you are more concerned with the outcomes from deploying the company's technologies than you are about the technologies themselves or the way that Microsoft chooses to structure itself to develop and sell them. Over the coming months you should be looking to Microsoft to fill out the framework and seek explanations for how the pieces fit together today and how the company plans to enhance that integration going forward. Labels: HP, ibm, Microsoft, Oracle, SOA
Microsoft server and tools is now part of the business division
The ever-vigilant Redmond watcher Mary Jo Foley over at ZDNet reports that Microsoft's Server and Tools unit (but not the P&L - Microsoft will still report server and tools financials), which is responsible for Microsoft Windows Server, SQL Server, Visual Studio, System Center management products and Forefront security products, is now part of the Business Division, the home of Office and Dynamics. Mary Jo finds this move 'curious' but I can see the logic. It's hinted at (if you get past the marketing speak) in the company's official statement that it made the move to: sharpen leadership focus on the company?s top priorities and align its organization for innovation, ultimately enabling it to deliver even more value to its customers.I think this is all about making it easier for Microsoft to articulate propositions which resonate with the key concerns of senior business and IT people. The reality is that key strategic business and IT initiatives - SOA, BPM, compliance ... - increasingly depend on multiple technologies and associated competencies, which cross traditional stovepipes. Big SOA, for example, is about managing IT work across the entire service lifecycle and so touches project and portfolio management, software development and integration, IT service management. BPM, as the other Neil pointed out, is about Office as much as it is BizTalk and Workflow Foundation. In the past, the way that Microsoft has been organised has worked against the articulation of such joined-up propositions (that's in part why it took the company so long to talk about SOA). Customers would get different answers to the same cross-cutting requirement depending on which Microsoft stovepipe they were talking to: you need BizTalk and SQL Server; you need OBA and SharePoint. [As an aside, I said much of this in an interview with Microsoft PR earlier in the week]. Obviously, shifting branches of the org chart is comparatively easy (even it is very big). The hard part is going to be changing behaviour, joining up the marketing etc. The creation of the Connected Systems Division back in 2005 shows that the company can pull this sort of thing off (albeit on a smaller scale in the Server and Tools Business as was) and Jeff Raikes, who now owns the combined entity, has the influence and power to drive things through at this larger scale. I am off to a Server and Tools Business analyst event in just over a week so I will hopefully learn more then. Labels: BPM, compliance, ITSM, Microsoft, SOA
New online SOA strategy planning tool - we need beta testers!
Over the past six months we've been busy working behind the scenes with a partner, JEMM Research, on a pretty nifty online SOA strategy planning tool. We're getting near to the point of launch, and we'd really like to find some people out there who would be interested in participating in a two-week beta test phase. Are you interested? The heart of the tool is a self-assessment model that looks at six dimensions of competence/readiness: concepts, strategy, architecture, organisation & people, governance, and technology infrastructure. You can see a small screen-shot of the (pre-beta) tool below.  Now we know there are a number of vendor-specific SOA assessment/readiness tools out there, but this one is a little different, for a couple of reasons: - It's vendor-neutral - it's not designed to steer you towards buying a vendor's product. It's not sponsored in any way.
- It's more detailed - the assessment at the heart of the tool has around 150 questions, and is designed to really make you think about how well you're implementing (or able to implement) a SOA initiative that has real business value.
- It provides some pretty cool feedback. The self-assessment, which is free of charge to use, provides you with overall scores in the six dimensions. You can go back to the tool as often as you like, and rerun the calculations to see how you've improved.
- If you want, you can pay a modest fee to gain "premium access" to the tool. With premium access the tool will generate, based on your self-assessment answers, a detailed and personalised SOA strategy action plan report. The report benchmarks your organisation against others of the same size, in the same geography and in the same industry as you. And most importantly, the report also contains a detailed set of actions you can take to improve your critical SOA related competencies. With premium access you can run the report as often as you like, whenever you like - so you can track your progress as you make your SOA journey.
If you're interested in being a beta tester, please drop us a line. We're currently planning on running the beta from May 14th to May 25th. Labels: MWD, SOA, strategy planning
Policy interoperability - a step in the right direction
At the end of last week a webMethods' press release popped into my inbox highlighting a recent demonstration of interoperability between the company's UDDI-based registry ( acquired with Infravio), HP's Systinet registry and one of Layer 7 Technologies' SecureSpan XML appliances. In a nutshell, the three companies showed how policies attached to services in a UDDI registry (using the Web Services Policy 1.5 Framework and Attachment candidate standard specification) can be exchanged with Layer 7's appliance for policy enforcement. Prasad Yendluri of the Office of the CTO at webMethods had this to say: greatly enhance[ s] the interoperability of all of the components used to achieve policy-based governance
a point which was reinforced by Toufic Boubez, CTO of Layer 7 who claimed such interoperability provides: a powerful standards-based solution for overall SOA management and governanceHere at MWD we certainly agree that a policy-based approach is essential for effective management of the service lifecycle. Policies should capture and enforce the obligations and expectations of service providers and consumers represented in service contracts to maximise the quality of the service experience. Interoperability of policies is also essential, given the variety of service infrastructure technologies required to support any significant SOA initiative. However, as I pointed out over a year ago: WS-Policy does not deal with semantics: it provides a framework within which those semantics can be defined. Support for WS-Policy provides no guarantee that the way one vendor defines a particular policy can be interpreted and enforced effectively by another. That will require agreement on semantics.For these reasons, I doubt that the three participants simply installed the products, created some services and policies and then demonstrated policy enforcement: they first had to agree how the policies would be represented in WS-Policy. Don't get me wrong: I think this is a positive step in the right direction. However, it's important for those involved in SOA initiatives to recognise, as I pointed out last year, that a number of significant steps still have to be taken to reach the semantic interoperability goal that's required:
It's not going to be easy! It will require the participation and cooperation of vendors of all shapes and sizes. Vendors, moreover, who are going to have to relinquish the control that ownership of policy definition can provide.
Labels: governance, HP, Layer7, policy, SOA, UDDI, webMethods
MWD FM SOA interview: TIBCO
We're nearing the end (for now - we have more planned, but not for a little while) of a series of SOA vendor interview podcasts with this one, which we conducted recently with Rob Myer of TIBCO. Rob works in Product Management at TIBCO with responsibility for SOA. We ask the usual four questions, and along the way swing by some interesting conversation points: - What you need from infrastructure in order to move towards enterprise-wide SOA, and what TIBCO learned from telecoms companies' service platform requirements
- The challenges associated with the WS-Policy, WS-Management and WSDM standards
- The application of CEP (complex event processing) technology to managed service delivery in the context of SLAs.
This podcast episode is 34'28" long. The podcast episode lasts 25'34". You can download the audio here or you can subscribe to the feed.Labels: MWD, podcast, SOA, TIBCO
Little SOA vs Big SOA
During our "off air" preamble with Miko Matsumura prior to recording our podcast earlier this week, he mentioned that he likes MWD's focus on "Big SOA". I'd never thought of what we tell customers about SOA in this way before, but it's true that we try and get people thinking about how SOA can help them transform their organisations in the long term by pushing the boundaries of SOA and not sticking with an overly-technical, bottom-up approach that sees SOA as "EAI with standards". So Miko got me thinking about what, precisely, "Big SOA" might be and how it might be different from something that for the sake of argument we might call "little SOA". So I came up with a picture:  As the picture shows, I think the difference between "little" and "big" SOA comes down to how you look at the "S" and the "A" of SOA. In "little SOA" (bottom left of the picture), organisations have a software development centric view of what a "service" is. A service is basically a standalone software component with some kind of remotely addressable invocation interface (let's say a WS-* interface for now). In "little SOA" organisations have a similarly narrow view of what "architecture" is - architecture is basically software design with a corner office. In "big SOA" (top right of the picture), organisations have a much broader view of what a "service" is. In this broader view a service isn't something you build; it's something that is experienced by a consumer. This view, therefore, is really about realising that delivering a service requires all sorts of IT competencies (design, development, integration, testing, deployment, admin, ops and change management) to be integrated together across the lifecycle of an investment that is packaged up as a service. That's a very different perspective on "service" that is not coincidentally much closer to what a business exec would think of if you asked them what a "service" is. In big SOA organisations also have a broader view of what architecture is about. Architecture isn't an inwardly-focused IT competence that seeks to make global optimisations to portfolios of software development projects. It's an outwardly-focused business-IT communication competence that seeks to further understanding of IT within business, and of business within IT. I don't have hard quantitative data to back this up, but based on anecdotal evidence of customer conversations my feeling is that the majority of companies considering or starting out with SOA are doing "little SOA". What do you think? Labels: architecture, service, SOA
MWD FM SOA interview: webMethods
Here's another in our series of interviews with vendors offering SOA "solutions". This time we spoke to Miko Matsumura, head of product marketing for SOA at webMethods. In this conversation we ask the usual four questions - and also chat about the importance of webMethods' SOA Link program, the role of the Infravio Governance Rules Engine, and SOA as an enabler of federated/cross enterprise business processes. The podcast episode lasts 25'34". You can download the audio here or you can subscribe to the feed.Labels: MWD, podcast, SOA, webMethods
MWD FM SOA interview: Microsoft
Here's the fourth in our series of interviews with vendors offering SOA related products and services. This time it's the turn of Kris Horrocks, who's a Technical Product Manager in the Connected Systems Division of Microsoft. (The Connected Systems Division was formed in 2005 as part of the Server and Tools business, and it brings together work on .NET, BizTalk, CardSpace and other related things). As usual we talk through our standard four questions. In the resulting conversation we explore: - how Microsoft deals with customers' questions about scalability and interoperability
- the importance of "high fidelity handoffs" between IT practices in quality service delivery
- how the SOA offering fits with Microsoft's Dynamic Systems Initiative (DSI) and support for "design for operations", and what this means for managing service lifecycles.
The podcast episode lasts 34'41". You can download the audio here or you can subscribe to the feed.Labels: Microsoft, MWD, podcast, SOA
MWD FM SOA interview: HP
Here's the third in our series of interviews with SOA vendors. This week it's the turn of Roman Stanek - one of the founders of Systinet, which was bought by Mercury (which was then in turn bought by HP a few months back). The 31'17" interview has some great stuff in it. As we ask our usual four questions about HP and Systinet SOA offerings, we swing past: - scenarios where the standardisation and interoperability that SOA introduces are particularly important
- how SOA is about outcomes, not protocols (with reference to the SOAP vs REST debate)
- how SOA wil disappear from the IT industry's lexicon in the coming years, because it will become a standard feature of the IT landscape
- the effect that SOA has on the software development lifecycle, and how the loose coupling that it introduces into development organisations and processes brings requirements for strong management of service lifecycles and service quality.
You can download the audio here or you can subscribe to the feed. Labels: HP, MWD, podcast, SOA
webMethods becomes SWAG
Apologies for the poor pun, it's the evening before the Easter break (public holidays on Friday and Monday here in the UK) and I'm feeling festive. So, it's finally happened. For those of us with the dubious title of "industry watcher" it's not a particular surprise to see webMethods acquired. We'd heard rumours for some time that the company might be readying itself financially and organisationally for a sale. Clearly the 25% price premium that Software AG (SWAG) plans to pay in purchasing the company at $9.15 a share represents a good deal for its shareholders, as webMethods' stock had got stuck around $7 for quite some months. But what is a surprise (to me at least) is the buyer. For one thing, we're used to big industry whales swallowing small specialist minnows: this is one medium-sized software company buying another medium-sized software company. SWAG's 2006 full-year revenue totalled in the region of $500m$650m. webMethods has a different financial year to SWAG, but its revenue in the equivalent period totalled roughly $200m. There's one particular feature of the two companies' income statements which is shared: both companies make more money from software maintenance than they do from selling new product licenses. Both companies are living more off their past success than their current success (although the balance seems as if it could be tipping the right way in SWAG's case). Software AG is a company with a long history as a middleware company, but it's not a glorious one. It scored huge success in the 1970s with the ADABAS DBMS and 1980s with the Natural language and development environment, but none of its more recent infrastructure product developments - EntireX (object and message broker), Tamino (XML database/integration platform) and Bolero (Java app server) have penetrated far beyond its established loyal customer base. What's interesting, though, is that with new SWAG products Centrasite (SOA registry/repository) and Crossvision (BPM, ESB, legacy integration, composite application development) now on the market, the webMethods acquisition certainly doesn't look like one to be based around technology. There's a hell of a lot of technology overlap. So this acquisition appears to be more about acquisition of customers and "mindshare" in complementary regions. Despite a US subsidiary with a long history (which started off independently in 1972, was bought by its parent in 1988, then spun off through a venture buy-out in 1997, and re-purchased in 2001), SWAG's visibility in North America is not high (any of our US readers heard of EntireX, Tamino or Bolero?). Despite webMethods' reorganisations which have cut back the size of its European operations over the past years, it seems to retain very high recognition in North America. What will I be watching? I'll be watching to see what happens to products and people as the two companies come together. Given the huge portfolio overlap, from a product and technology - and ultimately a customer - standpoint, this will be a difficult integration to pull off. UPDATE: John Conley, webMethods' Director of PR, got in touch with me to point out a couple of errors in the original post, which I've changed above. Labels: acquisition, SOA, Software AG, webMethods
MWD FM SOA interview: Martin Percival, BEA
Our second SOA vendor interview was with BEA's Martin Percival yesterday. Again we followed our standard format - and in the resulting 34'30" podcast we get into discussing: - BEA's experience of delivering "information as a service" projects within SOA initiatives
- How SOA is about more than just WS-* technology
- BEA's transition from a pure Java implementation focus to a broader focus, re-embracing its "legacy" middleware platform Tuxedo, the Microsoft expertise of its Plumtree acquisition, and also pointing to the SCA/SDO effort that it's a member of
- Why it bought Flashline (a software development repository vendor) and didn't buy a SOA registry vendor (it partners with Systinet/Mercury/HP)
- How its SOA 360 initiative will impact on the admin & management of the BEA platform.
You can download the audio here or you can subscribe to the feed. Labels: BEA, MWD, podcast, SOA
The SOA tool pyramid
I've had a bit of a graphic spurt (as it were) and so here's another blog post based around a diagram. I was talking to a journalist a couple of weeks back about the kinds of functionality that customers need to look for when looking for tooling for SOA initiatives, and which vendors provide which groups of functionality. It's not always easy to explain this kind of thing over the phone, so I thought I'd have a go at describing the main areas of functionality as a pyramid. Something like this:  In our assessments of SOA tool vendors' capabilities (see here for an example) we highlight nine separate areas of functionality, but this is a simpler picture that just focuses on four: - Service enablement - this is functionality that helps you take existing IT assets (applications, databases, etc) and create service interfaces based on the capabilities they offer. A lot of vendors provide facilities in this area because in truth most of them started out as integration tools vendors.
- Orchestration and composition - this is functionality that helps you aggregate services and create "composite services" or "processes". Most vendors offer some capability along these lines, and most involve the ill-named "BPEL" in some way (but that's another story). The reason is the same as the reason above: many of the SOA tooling vendors had "pre-SOA" offerings which allowed you to aggregate and orchestrate resources from existing applications and systems.
- Lifecycle management - this is all about supporting development, integration and operations teams in linking their efforts to ensure that the consumer service experience is high-quality and consistent under potentially unpredictable circumstances. Typically the foundation of this capability is some kind of registry/repository, but ideally tools go further than this - firstly by helping to automate team workflows for implementing quality controls at design time; and secondly by helping to translate design intentions relating to operational SLAs into runtime policies which are tied into the infrastructure. Some vendors are starting to offer capabilities in this area, through acquisition (HP/Mercury/Systinet, webMethods/Infravio, BEA/Flashline (kind of)); OEM/resale agreements (Oracle/Systinet, BEA/Systinet) or in-house development (IBM, Sun).
- Service development - this is about the ability to design services "from scratch", or to design services where any existing applications/systems offer functionality which only partially fulfils a requirement. Ideally this starts "contract first" - first of all documenting what the service needs to do and the commitments the provider should make to service consumers; and only then refining that spec into a working service implementation and interface.
Most SOA tools vendors suck at this last bit, frankly. I think that TIBCO is starting to do provide some interesting supporting facilities for this broad area with ActiveMatrix, and as vendors start to implement SCA/SDO in their tools the situation might get better across the board. In the meantime if you've heard of a vendor targeting SOA specifically that really provides solid tools to help with this kind of contract first" development approach, I'd love to know. Labels: BPEL, contracts, development, SCA, SOA, tools
BEA announces strategic partnerhsip with CA: but where does that leave AquaLogic Enterprise Security?
BEA today announced a stategic partnership with CA, which will see the latter's access and identity management solutions (SiteMinder and Identity Manager) integrated with the former's WebLogic and AquaLogic application and service infrastructure platforms. I agree completely with Wai Wong's (BEA's executive vice president of products) statement in the press release that Identity and Access Management is critical within SOA
not least because we have said as much in our service infrastructure assessment model and our report on identity management. Despite this agreement, I am still left a tad confused by this partnership as it is far from clear what this means for AquaLogic Enterprise Security (ALES), which BEA describes as a fine-grained entitlement management solution that combines centralized policy management with distributed policy decision-making and enforcement. This combination provides management and control of your critical applicationsHow will SiteMinder integrate with ALES? Will ALES continue to integrate with other identity and access management solutions? Does BEA plan to provide a common policy definition and enforcement framework across ALES and SiteMinder? We point out in our assessment of BEA's service infrastructure offerings that there are some important gaps when it comes to security and identity management, which explains why BEA felt the need to establish this partnership. However, as well as answering a number of questions from potential adopters, this partnership is going to raise a few more for existing customers with an investment in ALES. I for one look forward to learning more about the two companies' plans to validate and further extend integration between CA SiteMinder and BEA WebLogic and AquaLogic technologies
Labels: BEA, CA, identity, SOA
First MWD FM SOA interview: David Clarke, Cape Clear
We interviewed David yesterday and asked him our standard SOA vendor questions. Considering it was the first interview, we think it went OK... There were a couple of interesting things to come out of the interview: - Cape Clear markets itself as an ESB vendor, but its view of what is "in" an ESB is much broader than that of most other vendors - David in particular calls out BPEL-based service orchestration
- the sweet spot for the company is really a "mainstream", "mid-market" company which may not have much in the way of deep in-house web services or SOA technology skills
- the company is currently working quite a lot in software-as-a-service (SaaS) and other commercial service delivery scenarios - helping companies in the digital service delivery business create more sophisticated and valuable services
- David also specifically calls out the need for potential SOA "customers" to make clear distinctions between management of SOA-related technology, and management of the automated processes supported by that technology. These are two separate problems with different solution needs, and they should be evaluated as such
- it's pretty obvious from the conversation, we think, that Cape Clear is very firmly a technology company selling its capability as a standards-based middleware solution to integration problems. This makes it quite different from many of the other SOA players, which position themselves almost as business change agents.
The interview lasts 32'55". The audio file containing the interview with David Clarke is here - or alternatively you can subscribe to the podcast feed. Labels: Cape Clear, MWD, podcast, SOA
MWD FM kicks off interviews with SOA vendors
We let our podcasting get a little bit behind (well actually 3 months or so behind...) recently, and so we're trying to make up for it now. We have two initiatives underway, and this is the first (you'll find about the second one soon). We've just recorded the first of a series of interviews with senior representatives from IT vendors working to provide SOA-related offerings - the first is with David Clarke, EVP of Products at Cape Clear. The aim is to have a go at using the podcast medium to create a set of interviews which people considering or embarking on SOA initiatives can use as an additional reference in their selection process - kind of like an (albeit high level) set of comparable assessments in audio format... if that makes sense! In order to make these interviews as useful as possible we're doing three particular things. First, these are not sponsored podcasts. No-one is paying anyone for taking part in these interviews. Second, we're keeping each interview to around 30 minutes, so everyone gets the same amount of time to talk about what they're doing. Third, we're asking each interviewee to address the same four questions: 1) What are the commonly-occurring customer scenarios where your products and services get used? 2) How do you ensure that you "play well" with customers' existing investments - and where is this particularly important in your experience? 3) What are the main challenges that you help customers with - are you primarily helping them with service design, creation, assembly, management, etc? 4) How do you ensure that your technology is easy to deploy and manage? Obviously there are many more questions we could ask, but given the level of confusion and FUD that currently surrounds SOA and related technolog | | |
