With SAP Sapphire coming up it was only natural to find myself talking with my colleagues Jonathan who leads the UK practice and Frank who leads the Dutch practice about the changes and challenges in the ERP world. Not surprisingly both had some clear opinions based on their work and I suggested that both should share them via guest pieces on the CTO Blog. The first is from Jonathan.
I have been working with SAP NetWeaver and the developing Business Process Platform since 2003. In that time I have seen the emergence of a rich and increasingly complete SOA-enabled software platform. Despite some interesting development around Enterprise Architecture in that time, I wonder whether much has changed in typical SAP implementation projects?
The potential of the Business Process Platform is substantially different than yesterday’s CRM, ERP, SCM etc. platforms. Delivering SOA-enabled business content on a rich infrastructure offers the possibility of some very different deployment models for business solutions. Too often I find that the SAP team within the client organisation acting as the sole custodian of SAP solutions and that the Architecture Team (if one exists at all within the customer’s organisation) seen as the ‘enemies’ of the SAP team. Too often the Enterprise Architects are not even interested or engaged sufficiently in guiding and shaping the development of those SAP deployments within their business. If they do try, then they tend to operate out of their old-fashioned custom developed software paradigms. We are also frozen into the old way of very large-scale project deployments of business solutions – when, in fact we could be moving to a more rapid finer-grained deployment and enhancement of business capability.
How can we pull the world of the Enterprise Architect together with that of the SAP practitioner?

The Enterprise Architect’s job is to ensure alignment of the corporate IT estate with the requirements of the business and to mximise the value of the IT assets in the business. If the Enterprise Architect’s community continues only to glance at SAP solutions from afar – then they risk becoming increasingly marginalised as package-enabled SOA content emerges within the business. If the SAP Practitioners do not embrace Architectural principles, then how can they hope to maximise the potential of the rich platform that has been put into their hands by SAP AG.
Every corporate landscape is and will remain heterogeneous. Every value chain will involve potentially a multitude of business partners and solutions. SAP technology may well feature at many points within those value chains – but is unlikely to be truly ubiquitous. If there was ever a time for these two communities to start to understand each other, it is now. There is an emerging common language – based on the Open Group Architecture Framework (TOGAF) – presented as the SAP Enterprise Architecture Framework. While it doesn’t yet tell the whole story – it represents a significant step along the road towards package-appropriate Enterprise Architecture content. We hope that the next major release of TOGAF will itself contain an even richer set of package-relevant content and approaches to pull these two increasingly inter-twined but reluctant collaborators together.
We think that every SAP-using business needs an Architectural Blueprint to show how and where they will take advantage of the capabilities offered by Business Process Platform – alongside all the other technologies that exist within their own organisation. That blueprint also needs to contain the vision for how the business can take advantage of Web 2;0 and SOA technologies – how IT will enable these solutions in the future.
Every SAP practice needs access to people who understand the development of those all-embracing Enterprise views of where the IT landscape is going as well as access to people who understand more than just one vendor’s product set.
When you are delivering a new solution for your business – you aren’t restricted to multi-year programmes– locked into a sequence of massive functional implementations. (Finance, then Procurement, then Sales etc.). You should plan to move faster than that (unless genuine business constraints dictate otherwise). You need to be able to deliver new capabilities step-by-step – delivering business value at pace and at lower risk; maybe a Master Data Management solution, coupled with Business Intelligence platform could generate some quick wins – and lay a better foundation than traditional implementation methods.
You need to consider whether your own competency centre – or your implementation partner’s are set up to deliver the kinds of solutions you will need going forward. Above all of this you need that Treasure Map that shows you where you are trying to get to – and how that journey supports the business going forwards – the Enterprise Architecture Blueprint for your business.. As ever easy to say than to find the experience and knowledge to actually do it !
Jonathan Ebsworth