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
IBM to buy Telelogic: Rational, but not inspirational
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.
Labels: acquisition, architecture, EA, ibm, inside-out IT, Telelogic
Swimming against the tide
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?
Labels: EA, governance, language
Real-world Enterprise Architecture part II: conversation, federation, road trips and tools
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.
Labels: collaboration, discovery, EA, SaaS, sustainability
Real-world Enterprise Architecture part I: journey vs destination
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*.
Labels: collaboration, EA, sustainability
Zachman Framework != Enterprise Architecture
Just thought it would be worth linking to
this post I just made over at the
Technology Garden blog, the companion site for our
new book on IT-business alignment. See you over there!
Labels: book, EA
