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.

Posted by nmacehiter in Architecture • IT Governance • Software Lifecycle | Permalink | Comments (0) | TrackBacks (0)

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!

Posted by neilwarddutton in Architecture | Permalink | Comments (0) | TrackBacks (0)

Enterprise Service Bus (ESB) players often talk about their ability to support BPEL, and this is often mistaken for BPM support. But BPEL is a misleading beast (as I've blogged about previously). It's not a bad technology for helping IT folks with declarative specification of service-to-service integration processing, but it's not the same as BPM. This is often overlooked, and is where a good deal of the confusion surrounding BPM stems from.

The gap between BPM and BPEL is one perspective from which Cape Clear's recent tie-up with Appian - and Sonic's earlier tie-up with Lombardi - are newsworthy.

BPM initiatives need to be supported by technology that can flexibly integrate existing application, system and information assets into executing process instances. BPM pure-plays like Appian and Lombardi are both frequently tested against larger platform vendors (think IBM, BEA, TIBCO, Software AG, Oracle, etc) and, when standing alone, their integration stories are less comprehensive than those of the big boys.

Conversely, many SOA initiatives are pursued in the context of business process integration and improvement initiatives, and ESB specialists like Sonic and Cape Clear are frequently tested against the larger platform vendors, which on paper can offer more sophisticated support for runtime management of business processes. They certainly have more engineering and marketing resources.

So figuring out that partnerships between BPM specialists and ESB specialists are sensible is hardly rocket science. There are plenty of organisations out there which (for whatever reason) don't want to spend too much money with the big platform vendors, preferring instead to work with specialist suppliers.

What's more intriguing to me is how the separation of technologies forced by these partnerships can actually encourage good practice in "BPM + SOA".

It's often the case, where BPM and SOA tools are presented as part of broad tool suites, that separating business-focused process models from more technical models and service integration models is not encouraged in any meaningful way. Unless you work hard to keep these different models separate, over time artifacts which by rights should remain separate end up bleeding across models and it becomes harder and harder for different teams and stakeholders to remain actively involved in the programme, using tools and models that make sense to them.

By separating business-focused BPM modelling tooling from BPEL tooling and ESB configuration tooling, but still making it easy to link and reference where necessary between models and tools, these partnerships may well help to enforce good practice. It'll be really interesting to see how these partnerships develop, and whether the participants can make 1+1 = 2 (or more). If they can, then I agree with Sandy: these partnerships have the potential to create market-leading positions.

[Another interesting angle, IMHO, to the Appian-Cape Clear tie-up that's not really been picked up is that both companies are active in the area of SaaS. Cape Clear is doing quite a lot of work enabling integration of SaaS and on-premise capabilities for customers; Appian has a SaaS implementation of its technology called Appian Anywhere.]

Posted by neilwarddutton in Architecture • BPM | Permalink | Comments (0) | TrackBacks (0)

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.

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.

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.

Posted by neilwarddutton in Architecture • BPM • IT Governance | Permalink | Comments (0) | TrackBacks (0)

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?

Posted by neilwarddutton in Architecture • BPM • IT Governance | Permalink | Comments (0) | TrackBacks (0)

Oracle today confirmed

that 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.

Posted by nmacehiter in Architecture • BPM | Permalink | Comments (0) | TrackBacks (0)

I just came across this story at Application Development Trends referring to a report from ROI-specialists Nucleus Research which:

found an underwhelming correlation so far, based on a survey response. Of 106 enterprises surveyed, just 37 percent indicated a positive ROI from SOA.

The article and, I presume, the research focuses on the software development and integration aspects of SOA, rather than the broader service lifecycle and it's the latter where the real business value of SOA lies.

However, it's not this big vs small thinking that's the real problem: it's the search for mythical SOA ROI grail. You can think about SOA a bit like the plumbing in your office or investment in methodologies. It's easy to explain their benefits and their costs but there is only an indirect link between cause and effect. We have to move away from the comparative safety of spreadsheet ROI models and instead get out there and really sell it to the business, as we discussed in our latest signposts newsletter:

The problem is that when it comes to business managers in particular, SOA is just too involved a set of ideas to try and get across. Regardless of how relevant the underlying concepts are to senior managers, it seems that SOA as a term is something that?s seen as very technical. It?s tempting to think, of course, that this is not the way things should be, and that what we all need to focus on is education.

Most senior business managers have experience of having services provided by outside parties (facilities management; payroll processing; etc) and in some instances also have experience of providing or consuming "shared services". And we also find that many senior managers are also pretty sharp when it comes to understanding business processes and their management and optimisation. In getting buy-in for SOA initiatives, we find that quite often it's best to avoid "SOA" completely, and focus instead on helping business managers understand how the concepts of "service" and "process" in a business strategy context map down into more flexible and granular IT capabilities that can be developed, configured and reconfigured quickly as business service and process priorities change.

I am certainly not saying that the investment side of the equation can be ignored. It can't but costs need to be dealt with them in an incremental fashion, aligned with particular business benefits as an SOA initiative evolves. Trying to do that up front just doesn't make sense.

Posted by nmacehiter in Architecture | Permalink | Comments (0) | TrackBacks (0)

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

Posted by neilwarddutton in Architecture • BPM | Permalink | Comments (1) | TrackBacks (0)

I know in the blogosphere, waiting a few days to provide comment on an announcement like this one hardly puts me at the leading edge - but hey. Although I can't claim to be breaking any news, there are a couple of other points about IBM's purchase of Telelogic that I think are worth making.

As many other commentators have explained, in one respect the purchase of Telelogic takes Rational back to its roots as a tools provider to assist with the development of embedded systems. In this respect, the purchase of Telelogic is really all about IBM capturing market share and consolidating the market for engineering tools for complex systems development. This analysis was given extra weight by comments made by Danny Sabbah, the General Manager of IBM's Rational business, when he stressed that investment in Telelogic's tools and capabilities would absolutely continue. If IBM keeps the commitment made by Danny Sabbah, Telelogic customers can breathe a sigh of relief, and so will IBM. Embedded software developers love their tools, and many Telelogic customers will have made an explicit decision in the past not to go with Rational.

When you look at this (the biggest) part of Telelogic's business it's clear that this isn't just the usual story of mature markets consolidating, however. Back in 1999 I spent more months than I care to remember on this project, which convinced me it was only a matter of time before ubiquitous broadband networking, consumer electronics and the digitisation of content would open up major new markets for tools vendors. The "pervasive computing and content" thing is starting to happen in earnest, in a variety of sectors - including automotive, healthcare, consumer electronics, retail and travel. Where these things come together, consumer-friendly (and that means high-performance, highly-reliable, bulletproof) software is appearing in more places and in more guises. This is new market opportunity, and Telelogic gives IBM the chance to grab more of it.

So far, so Rational.

But what's been more interesting of late, to me at least, is not Rational's heritage but it's future direction. IBM has made it clear that Rational's focus is shifting from being a provider of development tools to being a provider of tools to help manage the process of software delivery - and helping customers turn IT inside-out. A big gap here has been in the provision of tools that really help customers model above the level of individual systems, and the surprise to me has been that although Telelogic has these (obtained when it bought Popkin back in 2005) IBM's early talk hasn't put much emphasis on their value. To me this is a major missed opportunity as it's a capability that more and more "mainstream" businesses with IT organisations are starting to realise that they need. Enterprise Architecture competency is quite thin on the ground and IBM has a chance to take a significant step forward in guiding customers here.

Assuming IBM does start to think and talk a bit more about Telelogic's enterprise modelling tools (which would seem to make sense, you'd think) my take is that this is one area where the technology would be best served within Rational's own product management structure rather than under Telelogic. As Rational moves its focus more towards managing the process of software development, the Telelogic assets naturally form a specialised sub-piece within the overall picture - but System Architect fits naturally alongside things like RAM, RMC, RPM, and some other stuff I can't talk about yet.

So - I really hope we start to see more from IBM about how the more mainstream capabilities of Telelogic will be taken forward, and if/how it will start to separate those mainstream capabilities from the specialist "complex systems engineering" capabilities.

Posted by neilwarddutton in Architecture | Permalink | Comments (0) | TrackBacks (0)

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 business

In 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.

Posted by nmacehiter in Architecture • BPM • IT Service Management • Software Lifecycle | Permalink | Comments (0) | TrackBacks (0)

Nick Malik poses an interesting question here - are we making things difficult for ourselves by calling Enterprise Architecture Enterprise Architecture? His point is (if I've got it right) that architecture work is kind of crunchy, focusing on very well-bounded and defined outputs - whereas EA work is delivered within a different context. Enterprises morph over time, and enterprise activity can't be controlled or designed in the way that a specific project can. EA teams don't (or shouldn't) define things with hard boundaries: they should attempt to influence growth and change. In the context of our book, our take here would be that EA is much more like garden planning than it is like cathedral design. As any gardener will tell you, unlike cathedral design, gardening is not a one-shot activity.

Moreover Nick echoes many others in calling out that EA work is often compared to city planning - and that city planners (or other similar types of entities) don't describe their work as "architecture". He has a great point - ideally EA shouldn't be called EA. It is a kind of discovery, planning, policy-setting and policy-enforcement practice - I'm even tempted to talk about it as a governance-like thing.

However we're hampered in this (as in so much else in the world of IT and business) because the language in this area has already been claimed. It will take a big effort to change the conversation.

Before we can do that, we have to settle on a term that makes sense and reflects reality, and this I think is the biggest challenge. Inertia is a powerful thing (how often do we change our personal banking provider, even though we're frequently told how important it is to consider?).

So - if not EA, then what?

Posted by neilwarddutton in Architecture | Permalink | Comments (0) | TrackBacks (0)

In my previous post I explained how in order to get real value out of Enterprise Architecture (EA) work, it's critical to focus not only on the outputs of EA work, but also on the process/practice of EA - and moreover that the process/practice has to focus on *conversations*.

What does this mean for tools, technologies and methodologies which purport to aid architecture work of different flavours? To get to the bottom of this, it's important to add another thought into the mix, which concerns the nature of IT work in large organisations.

What we found in our research for our book is that in large organisations (which are of course the organisations most likely to be pursuing EA activities) IT work is only very rarely truly centralised. Even where there is "officially" one central IT department, the reality is most often that there are other pockets of IT activity that happen elsewhere - perhaps in subsidiaries, remote offices, or within particular business departments. What we also found is that it's pointless trying to centralise IT work and force all IT activity to happen in one place. A top-down, centrally enforced IT mode of production might work for a short while, but soon enough entropy will work its slippery spell and projects will start springing up elsewhere (this is just one reason why the book is called the Technology Garden).

In reality, then, there's little point in planning and executing high-level architecture work in a highly centralised fashion, when IT work is actually federated. At least part of successful and value-adding architecture practice is going to be conducted on corporate road trips, not in bunkers or ivory towers.

So I'm starting to realise that a lot of architecture theory and method is not always very helpful.

At best the focus of the theory and method work can only be one part of a much wider picture, and it needs to be hidden from that main piece of the action - the business-IT conversations. We need new techniques, technologies and new skills to drive the conversations. We need tools and approaches that promote lightweight, collaborative and iterative work - tools and approaches which we can use to share ideas and edge towards agreements as we make those road trips.

There are lots of tools and approaches on the market that help people "do things right" in bunkers or ivory towers. But let's not forget that there's something that's at least as important as "doing things right", and that's "doing the right thing". Figuring out *that* part of the equation is where road trips come in. Where are the tools?

I really hesitate to use the terms "Web 2.0" or "Enterprise 2.0", but what's needed is an approach which builds off the kinds of capabilities you'll be familiar with if you're a student of those two-dot-oh-isms. Hosted platforms with universal remote access; and collaborative editing and sharing of information.

Embarcadero is planning on supporting this kind of scenario in future releases of its EA/Studio modelling tools, and Lombardi is already testing the market, from a process architecture perspective, with Blueprint.

Posted by neilwarddutton in Architecture | Permalink | Comments (0) | TrackBacks (0)

I was talking to Donna Burbank, Director of Enterprise Modelling and Architecture Solutions at Embarcadero a few days ago - she was briefing me about the company's new EA/Studio product. We digressed a fair bit along the way, particularly sharing notes regarding our experiences of how Enterprise Architecture (EA) *actually* works in the real world. A key point we discussed was the importance of focusing on EA as a journey, rather than as a destination.

It's all too easy to focus on the technical nature of EA outputs - which bits of the Zachman Framework should we complete? Should we mandate that all our models use UML? ... and so on. Now don't get me wrong, it's important to get a handle on the scope of your efforts, and try and create some consistency in what gets done - but these things are means to an end, not the end in itself.

Where I see organisations spending a lot of time worrying about the format and scope of EA outputs and artefacts, often, perversely, it comes about because there's a lack of organisational ambition regarding the role and contribution of EA as a practice. The hole left by a lack of ambition here is often filled by huge technical ambition - "let's model the world". We all know what happens if you follow that road too far.

For EA practice to have a valuable contribution, it has to be prepared to prioritise conversations with business people (and less so with other IT people) over conversations with other architects. Although that's not within the comfort zone of every architect, it's critical. Real architecture has to involve real stakeholder engagement - otherwise architecture is just design with a corner office.

Why is it so important to prioritise "external" conversations over noodling? Because more and more, business agendas dictate integration, harmonisation/rationalisation and collaboration efforts which have unprecedented scopes. Business teams and IT teams have to work together like never before to make these initiatives succeed, and a key plank is to create a competency that can understand and drive the kind of global (as opposed to local) IT optimisations that will enable businesses to drive their agendas forward in the 21st Century.

In summary: in the context of 21st Century business, the critical EA competency is the ability to drive shared language and multiparty understanding - and *conversations*.

Posted by neilwarddutton in Architecture | Permalink | Comments (0) | TrackBacks (0)

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.

Posted by nmacehiter in Architecture • BPM • IT Service Management | Permalink | Comments (0) | TrackBacks (0)

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 governance

Here 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.

Posted by nmacehiter in Architecture • IT Governance | Permalink | Comments (0) | TrackBacks (0)

Over the past few weeks, we've been busy interviewing senior representatives from SOA vendors and publishing them as podcast episodes. To make the interviews as comparable (and therefore as useful) as possible we tried to restrict each conversation to 30 minutes, and we asked the same four questions in each interview:

• What are the customer scenarios where your stuff typically gets used?
• Where is it important that your technology "plays well" with customers' existing investments, and how do you ensure that?
• What challenges in the lifecycle of services do you typically get involved in addressing?
• What do you do to make sure that your SOA infrastructure is itself easy to deploy and manage?

Posted by neilwarddutton in Architecture | Permalink | Comments (0) | TrackBacks (0)

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?

Posted by neilwarddutton in Architecture | Permalink | Comments (0) | TrackBacks (0)

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. 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, 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.

Posted by neilwarddutton in Architecture | Permalink | Comments (0) | TrackBacks (1)

At the beginning of March I attended Microsoft's Architect Insight event in Newport, Wales. The event is run by Microsoft but the idea is to try and stimulate a community of interest around IT architecture. The flavour is therefore not so much "listen to what Microsoft is doing" and more "let's talk about what architecture is, what's difficult, what's important, and how we can do things better". I certainly found it pretty interesting.

One feature of the event was a series of workshop sessions set up to explore a kind of "taxonomy of IT architecture". Participants were positioned on tables with peers with similar job titles/experience and asked to focus in on one or more roles, discussing what important features of those roles were and how the industry could potentially evaluate skills and experience. I could only attend one of the sessions, but at the session I managed to attend I was positioned on the "strategy architect" table.

Our small group was a bit non-plussed by this title, so instead we took things up a few levels and started with that perennial "what is an architect, anyway?".

Which is where I drew a version of this diagram:

The context of the drawing was this: we'd all come across people whose business cards said they were "architects", but who clearly weren't. Why not?

Well here's my hypothesis: if your role doesn't take you a fair way up at least two of the axes in the diagram, you're a re-branded systems analyst. In my view an architect:

• engages with multiple different stakeholders in doing their work - both from business and IT teams. They seek to engage those people to drive common understanding of the challenge, solution, costs and benefits and tradeoffs.


• plays some kind of role throughout the entire lifecycle of the IT investments they're involved in. Might not be hands-on all the way through, but they contribute.


• work across multiple systems, services or projects. In my mind the job of the architect is to try to optimise the value delivered across a portfolio of systems/projects. We're very good (mostly) at getting people to make local optimisations within system designs: we're not so good at balancing these with global optimisations that seek to pull IT activities closer to business strategy and direction.

What do you think? Is this a valid distinction? Is anyone else out there seeing lots of re-branded analysts, or is it just me?

Posted by neilwarddutton in Architecture | Permalink | Comments (0) | TrackBacks (0)

We've been meaning to blog about TIBCO's ActiveMatrix product family for a few weeks now, since we were briefed on it in December. However it took a while for us to get to a point where we felt we had something particularly "aha" to say about it.

What makes ActiveMatrix so potentially valuable is also what makes it a challenge. As TIBCOer Rourke McNamara said in a blog entry from Gartner's Application Integration and Web Services Summit: "Explaining what ActiveMatrix does in 90 seconds isn’t easy." Actually explaining it's value is more challenging, because it's not what you might expect from TIBCO.

TIBCO talks about "service virtualisation" and describes the core element of ActiveMatrix - the ServiceGrid product - as a "network of service containers" with "embedded policy management for service governance" and "JBI and SCA support for service deployment and provisioning".

These things are all true, and they're all cool.

But what does that really *mean*, in really straightforward terms? After talking to numerous journalists and clients about ActiveMatrix over the past weeks, we've evolved our introductory explanation to this one, when talking to non-expert IT audiences:

Back in the day, a big challenge faced by large organisations trying to develop and deploy systems was how to create systems relatively quickly, that were quick to change, in complex multiplatform environments. In those days the multiplatform issues was one of 16- and 32-bit Windows, Mac and OS/2 clients; Solaris, AIX, HP-UX, OpenVMS servers; and various kinds of databases and network protocols (this was when IPX/SPX and SNA were as interesting as TCP/IP).

A whole range of "second generation 4GL" environments were created which aimed to help. They married a high-level abstract programming language (the 4GL) to a virtual machine which was ported to all the major platforms and which hid the details of the operating environment - client, server, database, network.

Now let's fast-forward to today. Java and JEE and web-based application designs helped with some of that old multiplatform nightmare, but it's not the only game in town. What's more, now we're looking at SOA, the challenge today isn't so much about building discrete systems; it's about finding a consistent way to build and integrate system elements that can talk to each other within various parts of our companies, and also across different companies and whole supply chains.

In short we have another version of the same problem, only this time the multiplatform aspect is at a higher level - and the scope and scale of the operational environment are much bigger. Now we struggle to get "plain Java", JEE, .NET and other modern application containers to talk to each other, as well as other "legacy" application platforms - and Web Services protocols and standards are only a partial answer here at best. Even if protocol interoperability gets working better we're now looking at an environment which is widely distributed, and which may not be 100% under any one party's control.

So if we're to try and address today's challenge for SOA - to enable people building and integrating services to just concentrate on the core logic of what they're doing rather than getting stuck in the weeds of environment-specifics - we need something like the old 4GL virtual machine, but with lots of extra capabilities - like service provisioning (think about telecoms service provisioning if you know that industry) , and policy-based operational and lifecycle management of services.

That's what ActiveMatrix does. It provides a virtual machine environment for the SOA age.

As an aside: Why is ESB not the answer, and why is ActiveMatrix not an ESB? Because ESBs concentrate on solving just one part of this conundrum - the operational communication between services. From the developer's perspective the ESB is pretty much invisible (intentionally), and doesn't offer any "virtual machine" facilities to that audience. ActiveMatrix works on top of, around, and underneath ESBs.

Of course there's a proprietary element - although ActiveMatrix is built around JBI / JSR 208 and elements of the SCA specification, the container design itself is unique to ActiveMatrix. Interoperability is standards-based through JBI, but of course interoperability with something else is not the same as "swappability".

So here's a couple of interesting questions. Do companies pursuing SOA know they need this, and does TIBCO have the credibility to provide it? And is there enough momentum in the SOA movement to get the mainstream of companies to the point where they need ActiveMatrix, or something like it?

The credibility question is a good one, because it certainly took me a while to work out what TIBCO was doing with ActiveMatrix. I saw it completely as an integration vendor moving into SOA, and was completely unprepared for what TIBCO was trying to tell me - for a while it just didn't compute. We're going to need some excellent customer examples, well-explained, to really help people get in the right frame of mind to hear what TIBCO's trying to say here.

The second question is concerning to me as a student of IT industry history. The truth is that the history of the industry is littered with examples of situations where "movements" were cynically abandoned by vendors in favour of newer, shinier things, just as they got to a tipping point. If you can dupe your customers well enough, you can sell them A, wait until they get familiar with it, and then tell them that A is last year's model, and sell them the virtue of A'. Example: the demoralising arrival of SOA 2.0.

Many say that SOA itself is one of these cynical reinventions, and there is a grain of truth in that (but only a grain, I'd say). I believe that SOA has real value - and that in the context of achieving that value companies will need facilities like they can get from ActiveMatrix - but my concern is that we'll get derailed by the "next big thing" before we can all realise that value.

Posted by neilwarddutton in Architecture | Permalink | Comments (0) | TrackBacks (0)

Todd Biske of Momentum has a great blog on SOA and EA, and one of his recent posts chimed particularly with something we've been talking about for quite a while now - sustainability. This is a theme that we have been developing throughout 2006 for our book on IT-business alignment.

The idea of sustainability isn't really rocket science but it's a vital touchpoint in the process of strategic IT thinking. What it means is that it's not enough to think about technology in the context of solving a problem or addressing a need that you have today. To deliver sustainable value from IT you have to think about how technology will continue to address your needs going forward. Arguably this was a key challenge that contributed to so much disillusionment surrounding the Enterprise Application Integration (EAI) boom in the late 1990s and early 00s: EAI technology was great at fixing tactical and existing problems (how can we synchronise key customer data across these x systems? etc) but because of its sometimes esoteric (and certainly non developer friendly) nature a lot of the technology couldn't really support a strategic shift around how *new* capabilities should be developed to make integratability a "baked in" feature. A better balanced forward-looking approach to integratability (not just integration)is of course one of the things that makes SOA so interesting.

Todd's post is talking about how IT so often looks at things from the point of view of a set of discrete and disconnected events - and one particular piece grabbed my attention in the context of SOA:

"IT produces solutions, and then forgets about them unless a user complains or some alarm goes off. If an organization takes on SOA, but still operates with this mentality, the only thing that has changed is that they are producing services instead of applications."

Posted by neilwarddutton in Architecture | Permalink | Comments (0) | TrackBacks (0)

Jon is pretty busy at the moment finishing off the book (and I have a couple of minutes before some more editing) so I thought I would highlight his latest podcast over at BriefingsDirect where, together with a number of other independent analysts, they reviewed SOA in 2006 and made some predictions for 2007. You can download the MP3 here or read the full transcript here.

Posted by nmacehiter in Architecture | Permalink | Comments (0) | TrackBacks (0)

Nick Malik is an EA in Microsoft's internal IT organisation (which, by the way, has around 10,000 staff - hard to comprehend).
Anyone with more than a passing interest in EA and SOA should subscribe to his blog. Almost every post has a real "aha" moment in it. Check it out!

Posted by neilwarddutton in Architecture | Permalink | Comments (0) | TrackBacks (0)

I just came across this whitepaper from webMethods (who is not a client) SOA Governance: Enabling Sustainable Success with SOA. Putting to one side the fact that this is from a vendor and the checklist in the Appendix is clearly oriented towards webMethods offerings - based on the acquisition of Infravio earlier in the year - I have to say I am pretty impressed.

Too much of the discussion of SOA governance focuses on the design-time: adherence to standards, such as the WS-I profiles, schema validation etc. It ignores the fact that IT services, like services in the real world (think your mobile/cell phone service), are experienced by the customer, which is about more than just what is built by the provider. Because services are experienced, SOA governance must extend to the encompass the complete service lifecycle, from development through to operations: something which is acknowledged in the webMethods paper.

That being said, I do have a couple of quibbles:

Business involvement is called out during service change but not in the definition of the quality of service agreements, which comes across as the domain of the IT organisation. Business involvement is essential here to capture expectations and ensure that metrics are presented in a business-meaningful way

Service contracts are highlighted in the discussion of the SLAs - "how well" a service is performed - but not in terms of the functionality provided by the service - the "what" - and the commercial aspects of service provision - the "how much". If an SOA approach is to really deliver business value then it must be possible for business and IT to establish some common ground in terms of service expectations and comprehensive service contracts, which encompass all of the aspects of those expectations, do that.

Bearing in mind those two important consderations, the paper is worth a few minutes (as are our reports on SOA and SOA quality management which provide our perspective on some of these issues).

Posted by nmacehiter in Architecture • IT Governance | Permalink | Comments (0) | TrackBacks (0)

My latest podcast appearance, together with Dana Gardner, Steve Garone and Joe McKendrick is now available (or you can read the transcript here). This episode focusses on SOA-related news from Oracle's OpenWorld conference, including some of Oracle's Web 2.0 aspirations, and concludes with a discussion of the company's Unbreakable Linux announcement.

Posted by nmacehiter in Architecture | Permalink | Comments (0) | TrackBacks (0)

...part of the title of two recent posts (here and here) from one of my absolute favourite bloggers on SOA, Steve Jones (CTO of Application Development Transformation, Capgemini). Anyone trying to understand what SOA is really about, in real-world practice, should read these.

The very short executive summary (of these and his general theme): SOA is about your entire organisation's attitude to how it thinks about itself and about its relationship to technology - it's not about ESBs, BPEL, or any of the rest of that alphabet soup.

This guy hits the spot with almost every post and he's not afraid to tell it like it is, warts and all.

Some Friday reading for you!

Posted by neilwarddutton in Architecture | Permalink | Comments (0) | TrackBacks (0)

Last week I had the opportunity to join a podcast debate with Ronan Bradley, Joe McKendrick and David Linthicum, looking at the question of reuse within SOA initiatives - why is it difficult, and should it be the thing we're aiming for, anyway? Perhaps it was disappointing that there wasn't much disagreement: nevertheless I think we hit on a lot of good points.

From my perspective the things that came out were:
- don't fall into the trap of creating services "because you can" - that way you're almost certain to fail in even promoting service use, let alone reuse
- focus on the "A" of SOA - "it's the architecture, stupid"
- look at reuse as one part of the overall value of SOA - along with more flexible infrastructure and applications; lower risk software projects; more business-comprehensible systems; and so on
- when looking at vendor case studies and marketing messages around reuse, take all claims with a big pinch of salt.

Posted by ebizQ in Architecture | Permalink | Comments (0) |