One Reason Why SAP's ESA Proposition May be a Healthy Step Forward

I recently was at SAP's head office in Germany to hear from them about their ESA (Enterprise Services Architecture) initiative, and it was an interesting session. They are positioning ESA as the unifying concept, an a branded guiding vision overarching their newer Netweaver technology stack, and their more traditional mySAP application suite.

This post isn't really to comment on their particular offering, but what I was most impressed about was that a software vendor, wasn't talking about software, or technology, but about the Architecture of an Enterprise's IT, and the value to a Business of an Architectural approach. Now, of course they are doing this as a means to sell more software, but putting scepticism to one side for a moment, it was an important step.

My reason for saying this is that for a couple of years now SAP has been promoting Netweaver. And in most ways Netweaver is in the same space as lots of the software infrastructure technology vendors' offerings. Accordingly, the Netweaver SOA promotional material and positioning had large parallels to the software infrastructure technology vendors' SOA material and positioning. But ESA is more than that, it acknowledges that SOA is bigger than just a technology buzzword, is bigger than a set of enabling software infrastructure technologies (such as Netweaver) however good.

The point here is that the technology, even if it is created with an architectural approach (e.g. SOA) in mind, will not make that architectural approach happen. It's refreshing to see that coming from a software vendor that is so connected within so many of the world's big Enterprises.

A good example of the shortcomings of the SOA technology focus is the integration vendors, who have been selling the value of SOA for longer than most. The software they provide is just an enabler, and a partial enabler at that, for the SOA approach. Usually such vendors will articulate the SOA concept in generic and abstract terms, and as 'proof' will encourage a small pilot project to prove the value of the architecture. Now I have nothing against using pilots to prove value and contain risk, but those pilots run the risk of being technical proofs-of-concept (the goal being to close the software deal) rather than actually indicative of the SOA objectives, and the value-proposition that needs to be driven throughout the Enterprise.

Enterprise-level Architectures don't come about through technology-led pilot projects, they require Enterprise-level Vision and Leadership, Strategy, Skills, Methods, Governance ... and supporting Technologies. What we must avoid is a technology and buzz-word fixation driving the creation of a new set of legacies.

Technorati Tags: enterprise architecture SOA SAP SAP ESA SAP Netweaver

Being a Little More Circumspect about Services Dogma

I was talking with one of my colleagues recently about SOA hype. His view was that there are too many Enterprise IT people out there that are preaching SOA as if it's a lesson for business. They speak as if they've discovered something that business people have never thought of, and that if business people just listen to them then ...

His point was good, that this is not helpful. I'm sure some EA-people will disagree with me on this, but Enterprise Architecture is largely about better arranging IT in relation to the business and its demands. The Service-Oriented approach to Architecture is about designing, constructing, and delivering IT using approaches that are aligned to those business uses rather than seperate and requiring translation at every turn. So IT preaching to business about the value of services runs a real risk of being the cart leading the horse.

This was obviously a bit of a pet topic of this colleague of mine, because he went on to talk about how some of the hyped benefits of SOA are also not helpful. Talk of increased agility is confusing at best, but suggesting that business processes will be changed on the fly, and business models will be dynamic and ever-changing, is just down-right scary to many business. Let alone being impractical and unrealistic.

The enthusiasm around SOA is good to see, but we've got to keep it real, because if the case is over-made or inappropriately-made, then it's all too likely that credibility will be lost, and expectations missed.

Technorati Tags: service-oriented SOA

Enterprise Architecture is not Software Architecture (and it's not Technical Architecture Either)

In what I do day to day, I often get asked to explain what Enterprise Architecture (EA) is. Rather than give a long and complicated answer describing frameworks and methodologies, or processes and information, I long since learnt that it's often best to introduce it really simply. This might be by stating that EA was really the application of the discipline of Architecture, as it has evolved in the physical world of construction, into the business world of Enterprise IT. Therefore it fundamentally was the discipline of translating what 'the owner' (or the client) wants (or what they actually need), into things that can be designed and built by 'the builders'.

In many ways architecture in the physical world, and the Enterprise IT world, is the bridge between strategy and delivery. Covering the gap between the big picture of what you want or need to do (your strategies), and actually what gets done when the rubber hits the road (the delivery).

But that is just the green-field view. Architecture also includes the lifecycle maintenance view. That is, how what was originally built can be adapted, changed and maintained over its lifetime, as the context or needs of the owner change. After all, change is inevitable.

John Zachman explains this well by pointing at a wall and announcing that if you needed to change your building for some new purpose or challenge, and wanted to (for example) remove a wall, you'd have three options.
*- You could knock down the wall and see what happens. (Hmmm...)
*- You could employ engineers to spend significant time drilling holes in the wall trying to work out how it's constructed and how it can be removed. (Sound familiar?)
*- Or you could dust off the plans for the building and do the necessary calculations ... (That is if you had the plans of course ...)

But that's still not the whole of it, there's another dimension to this. The dimension of Enterprise vs Solution. If Solution Architecture is like the building and maintaining of a large (commercial) building or complex, then Enterprise Architecture is more akin to City Planning.

A City Planner has to control and guide the evolution of a City where there are many different groups of stakeholders, with mostly independent objectives and priorities, and each with its own legacies. So there are buildings already in place being maintained and extended by separate groups, each with their own objectives and motivations. At the same time there are many projects designing and building new buildings, all again staffed by separate independent groups, each with their own objectives and motivations. Then there are various shared robust infrastructures for roads, water, electricity, gas and sewerage to maintain and keep cost efficient. And finally, in addition to all of this there are all of the abstract aspects of the City that affect quality of life and require management, such as safety, community, atmosphere, aesthetics etc.

The parallels between this analogy and Enterprise Architecture in IT are simple and intuitive.
*- IT projects run in parallel each with their own business case, competing for common resources, sharing strategic infrastructures. Each needing control and guidance to ensure they strike the balance between the quickest and cheapest route for the project and it's individual business case, versus the most responsible and acceptable route for the Enterprise as a whole (looking beyond the completion of the project).

So that's a thumbnail sketch of Enterprise Architecture. Design Enterprise Solutions for new builds, and maintain design through life. Plus, design for projects to build new solutions, but also for the Enterprise making sure that all the projects play nicely together and all contribute positively towards taking the Enterprise as a whole where it needs to go.

All that explanation and there hasn't been a single mention of Business Processes, Applications, Information or Data, Software, or Hardware. Well of course they all are parts of Enterprise Architecture, that's the next level down. And precisely there is where the complication the title of this post suggests comes from. All the various IT legacies and imbalances bias what has so far in this description been a simple set of concepts.

The complication I'm referring to is that lots of the content about IT Architecture to be found on the internet is actually about Software Architecture. That's fine, and Software Architecture is a very valuable discipline (how to best design software systems and platforms), but it is only one piece of one layer of the Enterprise IT Architecture.

To make things more complicated, when you mention Enterprise Architecture to someone in Enterprise IT, for example a Programme Manager, they often assume you are talking about Infrastructure (the hardware, networks, platforms etc) and start talking about how your Technical Architecture will be very useful for their big application implementation project.

Technical Architecture is also a very valuable discipline, and certainly pretty much any project is going to need a suitable one to be successful when live, but again it is only one piece of Enterprise IT Architecture.

The point is that, apart from confusing what is Enterprise Architecture, and potentially mis-setting people's expectations of what it will deliver, it misses the fact that the discipline of EA is based around the linking of the software architecture with the technical architecture, and the applications architecture, as well as all the other 'aspects'. These very linkages are where a significant amount of the value of architecture lies. Without the linkages between the different type of architecture, there is a risk that each area becomes its own little fiefdom of technical 'best-practice', and each time has to reinvent the wheel, which doesn't help IT's credibility with the business. Indeed, the linking of the areas together holistically in one mature managed discipline, with the specifics of the Enterprise (rather than generic IT concepts), are key to making EA such a powerful approach.

For those that are interested, of course there are some very good overviews of true Enterprise Architecture approaches on the web. Being slightly biased I might point towards Andrew Macaulay's piece on EA from the first Microsoft Architect's Journal, for an example of one that goes into the next level of detail. But you can't really beat John Zachman's introductions to the subject to articulate it the best. ZIFA is the Zachman Institute for Framework Advancement where you can find many of his articles. Or even better see if you can make it to one of his seminars which you should be able to find via Google fairly easily (in Europe they're run by IRM UK). I'm sure this discussion will run and run.

Technorati Tags: enterprise architecture IT Governance