Avoiding the “I’m Spartacus” scenario in SOA.

Remember the movie “Spartacus” – the Stanley Kubrick classic starring Kirk Douglas? In the movie there’s a famous scene where the bad guy’s (the Romans) want to capture Spartacus (Douglas) who’s the leader of a Slave army. After a huge battle the Slave army is defeated and the Romans promise that no further punishment will be dished out as long as the slaves identify their leader, Spartacus. “Who among you is Spartacus?” ask the Romans. To which, one by one hundreds of guys each reply in turn “I’m Spartacus” thereby protecting their leader by creating a huge array of ‘false positive’s‘ so that the Romans can’t properly identify the one true Spartacus.

What’s this to do with SOA?

In large SOA programmes I’ve seen a similar scenario where all of a sudden, multiple in-flight projects each start to claim that they are delivering ‘the SOA’. However, in reality very none of them are because it all hinges on how you measure ‘SOA’.

This ‘SOA Spartacus’ scenario usually occurs quite soon after SOA is articulated as the primary strategic direction of the programme, but before the organisation’s SOA capability is mature enough to understand what is meant by SOA, and how it should be designed and delivered. The problem occurs because people are inherently good, and they want to be seen to be doing the right thing even when exactly what constitutes ‘the right thing’ is not terribly well understood.

The risk for these SOA programmes is that should this situation be allowed to continue, the organisation may ultimately deliver none of the strategic benefits of SOA because the project teams are not properly coordinated and each ends up doing SOA very differently.

The Solution:

The solution to the problem is in two parts. Part one is to have a clear understanding of what constitutes SOA in your environment by creating a single set of SOA Design Standards.  Part two is to provide robust SOA Governance so that adherence to the standards is universally enforced.

1. SOA Design Standards.

Business-aligned and intrinsically interoperable service-oriented architecture can only be created by widespread adherance to a consistent set of SOA design standards. It needs to be made very clear what does constitute good SOA within your domain and what doesn’t. Your service design standards should support the SOA design principals and ensure that the goals and benefits of SOA can be achieved. The overall policy of the SOA programme should be to enforce the SOA standards using SOA Governance…

2. SOA Governance.

In order to avoid deviation from the SOA standards and policies, you need to introduce an element of governance & control across the whole SOA programme that can ensure that the SOA Design Standards are applied consistently by each project team. If you do this it’s far more likely that you’ll get the outcomes you want and that the resulting SOA will meet the strategic goals of SOA.

Finally, a simple shortcut.

If you’re planning a SOA programme, quickly obtaining maturity in SOA design and implementation will save you a small fortune and help you avoid these simple gotcha’s. If you don’t have a SOA expert on your team, then my advice go and get one as soon as possible. It could be the best decision you’ll ever make. I’m confident you’d see a respectable return on that investment in a very short space of time.

Book Review: EJB 3.1 Cookbook

Being a SOA Architect, it’s been a while since I had to code a Java Enterprise application (a.k.a J2EE  or JEE application) but I am still very interested in maintaining an up to date knowledge of the technical advances in the Java Enterprise platform so that I can fully understand the design implications and the implementation opportunities presented by the platform’s new features.

Enterprise Java Beans 3 (EJB 3) is a major update to the JEE platform which debuts annotation based aspect-oriented configuration and provides new services for entity persistence and new bean types to handle things like timers and scheduling in enterprise applications. This is a new and very efficient approach but it’s very different to the deployment-descriptor based approach of J2EE. There are plenty of EJB tutorials and individual examples on the web, but if you want a fast but still comprehensive coverage I always think you get further with a decent guidebook in hand.

Richard M Reese’s “EJB 3.1 Cookbook” is just such a guide. It’s a quick whistle-stop tour of the EJB 3 platform and covers all the new bean’s and annotations and also covers related hot topics like Web-services using SOAP and REST.

My aspiration in reading this book was to get a quick technical refresher on Enterprise Java Beans and then put this newly obtained knowledge to the test with some additional coding for the my personal SOA reference platform.

Each chapter in the book details a specific part of the EJB technology set. The JEE topics covered by the book include:

• Session Beans (EJB’s)
• Message Driven Beans (MDB’s)
• EJB Persistence (Entity Beans with JPA)
• EJB Persistence Queries (JPQL)
• EJB Transactions
• EJB Security
• EJB Interceptors
• EJB Timer Services
• Web Services (JAX-WS, JAX-RS)

Each topic is split into a selection of individual technical ‘recipes’, each written using a predictable format as follows:

• “Getting ready” provides an overview of how the recipe works.
• “How to do it…” provides a full description of how to achieve the recipe’s objectives.
• “How it works…” explains how any code samples are pulled together and explains any code referenced in the previous section.
• “See also” identifies any other recipes that may include pertinent information to assist the reader in their understanding.

By following this format the book is astonishingly easy to read. The simple structure means you can plough through it quickly from cover to cover if you want to or you can dip into it for hints when faced with a specific coding challenge.

Usually, code based tutorials and discussions can be a real bind but in using this recipe format Richard has avoided the lengthy code samples that you often see (the ones that usually send me to sleep). Instead he uses a tightly focussed code highlighting technique to illustrate his salient points. It’s an approach that works really well for experienced coders or those like me who are just looking for a refresher. However, novices or those looking for lots of detail may need to look elsewhere because a certain amount of experience with enterprise level coding, application servers, IDE’s, build tools and testing tools is helpful but these topics are not covered in the book.

Overall this book works really well as a technical refresher and really makes it easy to get started with EJB 3.1 (especially if you’re already familiar with some aspects of the JEE platform).

The JEE platform itself has gained some very powerful and useful features and from a SOA implementation perspective, the addition of JAX-WS, JAX-RS and EJB Interceptors into the mix means that JEE is now a great platform for SOA implementing using either SOAP, REST or EJB components.

In conclusion.

I’d definitely recommend this book to anyone who has some experience of Java EE and is interested in the technical advances of EJB 3.1 and the opportunities those new capabilities bring. However, if you’re a novice or you’re looking to get started with EJB for the first time, I’d image you’d be better served by a book that has designed with novices in mind.

My latest article on InfoQ

InfoQ have just published an article of mine entitled DIY SOA: Building your own Simple Service Repository.

You can read the article in full here: http://www.infoq.com/articles/SimpleServiceRepository

You can also see the cloud based demo of my version of the Simple Service Repository web application here: http://soagrowers.jelastic.com/simpleservicerepository/index.jsp

Ben Wilcock – SOA Certified Professional (SOACP)

After completing 2 of my Prometric exams with SOASchool.com, I’m pleased to announce that they have awarded me the status of ‘SOA Certified Professional‘.

You can read my blog posts about the individual courses that made up this certification here and here.

About SOASchool.com and the SOA Certification Programme.

The SOA Certified Professional (SOACP) program is dedicated to excellence in the field of SOA and service-oriented computing. Through a series of seasoned course modules and exams, IT professionals have the opportunity to obtain a number of different certifications to recognize their accomplishment of gaining project-ready SOA proficiency.

This vendor-neutral program was developed in cooperation with best-selling SOA author Thomas Erl and several major SOA organizations and academic institutions. Through the involvement of the SOA Education Committee, course contents and certification requirements are constantly reviewed and revised to stay current with developments in the service-oriented computing industry.

SOA Certified Architect: Module 2

SOA Technology Concepts.

Regular readers will already be aware that I’m working towards becoming a SOA Certified Architect with the independent SOASchool.com. This training and certification body is chaired by a group of independent industry experts led by Thomas Erl the leading author on service-orientation.

I chose this certification programme precisely because it’s independent and vendor neutral. Vendor diversification options and greater implementation choices are one of the major advantages that SOA has over other architectural models, so it seemed to me that there would be little point taking an IBM, Microsoft, SAP or Oracle certification.

The standards that bind SOA together are not owned by any one vendor, but by standards bodies like the W3C, OASIS, and WS-I. Therefore, at best a vendor will only ever have their own proprietary view of how to implement these standards in their current software stack. It’s this implementation specific view that can creep into their certification programmes and therefore limit your future options and depth of general understanding (in my opinion).

This second module ‘SOA Technology Concepts’ covers a very broad overview of all the relevant technology and implementation concepts for service-oriented architectures including…

• SOA Implementation Technologies (Components, REST, SOAP, WSDL, XSD, XML, UDDI, WS-Policy).
• Standards and standards bodies.
• QoS Standards (WS-Coordination, WS-AtomicTransaction, WS-BusinessActivity, WS-Addressing, WS-ReliableMessaging, WS-Security).
• Orchestration Standards (WS-BPEL)

It also covers the details behind some of the terminology used throughout the course like ‘Service Activities’ and ‘Service Roles’.

As ever the course content was clear and concise, and if you follow the instructions in the course module booklet you should have no problem in passing the associated exam. The vendor independence is very apparent, with no specific preferences one way or another in either the course booklets or the associated printed textbooks. This is great, because it’s not anti-vendor, but it does help you to understand that in SOA the technology revolves around the standards and that for the first time this creates a level playing field for everyone to compete on.

The exams themselves are pretty tough; 50 questions lasting an hour with a fairly high 80% ‘standard’ pass rate (even higher still if you require an honours grade as I do). After the exam it would be really nice to know which questions you got wrong so you could learn from your mistakes, but this isn’t an option. In my case I suspect that my wider implementation experience inclined me to give more optimistic answers than required to one or two of the questions which just prevented me from a perfect score. Ho hum.

The customer experience from Prometric is still only average. For this exam I had to travel twice as far to find a test centre because my local one had decided to shut down their exams and assessments for most of the summer while they relocate to a new office. Bizarre. Still, the exam itself was complementary, as compensation for the confusion over my first attempted exam a couple of months ago (where the test centre had closed but failed to inform every candidate). Prometric’s customer services are very good, it’s just the availability of test centres and the on-line administration system that are lacking.

Overall it’s been another thoroughly enjoyable experience. On to the next one…

There’s no such thing as a pre-packaged SOA.

It’s unfortunate, but Vendor’s, SI’s and VAR’s regularly mis-sell SOA.

Let me give you one simple example…

About 12 months ago during an RFP demonstration, a big name software Vendor suggested that their “3,500 ready made services would deliver SOA out of the box”. They even claimed that somehow 3,500 services was a mathematically optimum number an implying that everyone would need this number of services eventually-  so why try and do it yourself?

Clearly this promise of a ready made service inventory could be very tempting to the uninitiated – but it’s just plain wrong. It’s like someone dumping a keyboard with 3,500 keys on your desk and then telling you that it can make you type faster. It’s simply not true.

In reality this particular vendor’s API had more likely been the result of a quick and dirty hack to expose an old functional API as a bunch web services. They could do this by simply turning each ancient API function into one operation on one web service. But the resulting service inventory would be a vast and unfathomable hodgepodge where every service API was designed at the same level of granularity and with the wrong level of coherence (both OO terms but they’re appropriate here). Ultimately this leads to an implementation nightmare where a considerable amount of complex service composition would be required in order to perform even the most basic of tasks.

Furthermore, regarding the 3,500 web services is optimal claim, the only math that I’m aware of that would make a difference to service interface design is Partition Theory and Partition Theory quite clearly states that a simple 1:1 mapping of services to operations (like those in this particular API) is very rarely the optimal arrangement and would more likely lead to highly inefficient solutions.

When challenged about this, the vendor’s ‘ingenious’ solution (I’m being generous here, I actually mean ‘demented’) was for the client to licence some more of their SOA tools to help with the burden created by this massive inventory of services. They’d need a registry to help with the discovery problem and a process management tool to help develop the large number of service compositions they’d need to build to do anything useful with their 3,500 services. This would of course require additional capital outlay, infrastructure and training and would inevitably deepen the vendor lock-in even further.

Fortunately, my private sector client at the time did evaluate the situation correctly and didn’t take the proposal any further. However, in less experienced teams this kind of mis-selling could go completely unchecked and could end up costing organisations a small fortune in scope creep and additional integration and implementation effort.

So what’s the solution?

I’d like everyone to understand this simple fact and use it to their advantage:

SOA can’t be packaged and sold!

The only way to get an architecture that is naturally service-oriented and fits the way that your business operates is to design it that way. There is no such thing as a pre-packaged SOA that can be bought off the shelf. Service-oriented solutions need to be designed by you, for you.

Vendors, SI’s and VAR’s currently find it all too easy to exploit customers who don’t have an expert SOA practitioner on their team. So my advice is for you to do yourself a favour and go and get one as soon as possible. It could be the best decision you’ll ever make and given the prices quoted by SOA vendors I’m confident you’ll see a phenomenal return on that investment within a very short space of time.

How to build a DIY Service Repository

This article has been expanded and is now available in a longer format on the InfoQ website under the title “DIY SOA: How to build your own Simple Service Repository“. There is also a demo version of the web application part of the solution available for you to explore here.

Every Jedi faces the moment in their life when their Lightsaber simply fails to perform as expected and he or she has bite the bullet and build a better one.

Not being a Jedi I clearly have no use for a Lightsaber, but I did have a recurring irritation in the form of the service registries and repositories. These tools often claim to support good SOA principles and practices (like discoverability and contract-first service development) but in my view they often fail to live up to the hype.

Service Registries/Repositories fall into two basic camps. There are the commercial large vendor offerings from the usual suspects and the smaller open-source attempts.

Being a lightweight agile kind of guy (not literally, sadly) I’m constrained a strong value-vs-cost ethic. To my mind the commercial offerings are basically too bulky, too demanding and too expensive to be of any interest. That leaves the open-source offerings, which are rather thin on the ground, can have limited functionality and are not terribly well thought through in terms of the functionality that I think multi-disciplined team of users would need.

So to cut a long story short I decided to build my own ‘DIY Simple Service Repository’ using low-cost open-source tools and technologies.

What I wanted from my Simple Service Repository.

A good service repository should support the principles of good service-orientation. Specifically, a service repository should allow for a high degree of service contract standardisation, support contract versioning, promote contract-first service development and enable easy service discoverability (preferably at both design time and at compile time). Let me explain what I mean by these requirements.

Contract standardisation is the practice of supporting abstraction, loose coupling, federation and reuse in service contracts by centralising artefacts like XML Schemas, abstract WSDL‘s and WS-Policy documents. Reuse of XML Schema’s is particularly important as it is a key enabler for ‘intrinsic interoperability’ whereby services communicate using the same data model. By having all my contracts, data models and policies in one place I can reuse them easily and as often as I like.

Contract versioning can be quite a difficult process but I want a simple solution where all the decisions regarding the versioning of contracts, policies and data models are mine. I’m not going to ask much from my simple service repository, I simply want it to hold ‘releases’ in separate version controlled directories that are independent of each other. I’d like releases to be addressable via a URL and be viewable in the users browser.

Contract-first development (of SOAP based web services) is important because it ensures that the service contracts remain loosely coupled and independent from the underlying implementation technology. Contract-first often entails a service designer designing the required contracts and developers ‘importing’ them into their build as the basis for a service’s implementation code. This can often be a source of some discomfort for developers who may be used to controlling their own destiny, so making it an easy process can help to overcome any potential objections that may arise.

Finally, easy service discoverability benefits service-oriented architectures because by making services highly visible we can reuse them more readily and also prevent ‘accidental’ duplication from occurring. Duplicate, competing, unused or redundant services can confuse and dilute the effectiveness and power of your SOA, hampering its ability to serve its community. These issues can be avoided (and reuse promoted) if service contracts can be easily discovered by anyone at any time.

By creating a place to centrally store service contracts (and other design time information like WS-I BP compliance documents or human readable interface documentation) we can achieve all of these goals and add some real value to our SOA analysis, design and development practices.

Enter: The SOAGrowers ‘Simple Service Repository’.

So here is my solution. Just follow my 3 simple steps and you’ll have a simple service repository in no time…

1. Create a Java web application (the Simple Service Repository application) using Maven.

The source for this project is hosted in my SVN server. The application includes browsable folders for the WSDL, XSD and WS-Policy documents and SVN keeps everything nicely version controlled. HTML and CSS provides the basic glue that binds everything together, but you could investigate using a Wiki maybe if you don’t like HTML. I’ve included some screenshots below if you want to see what it looks like in real life.

2. Build & Deploy the Simple Service Repository application to an application server.

Jenkins is an open-source continuous integration server and sits as another application on my Glassfish server. Jenkins is configured to build and deploy my application whenever it notices a change in the SVN repository.

Glassfish 3.1 is my personal application server of choice for Java web applications other servers could work just as well. Once hosted, the Simple Service Repository’s HTML pages are instantly available via a browser and I’ve also used a specific Glassfish deployment descriptor which makes my content folders browsable by default.  These features help satisfy my basic ‘discoverability at design-time’ requirement.

When Jenkins builds my service it calls Maven’s ‘install’ which places the Simple Service Repository web application [WAR] and all the service contracts it contains into my Maven repository as a versioned Maven artifact. This is very handy for the next bit…

3. Build a SOAP based Web Service from a contract hosted in the Simple Service Repository (and test it).

Maven again comes to the rescue again, using a Maven ‘copy’ plugin to extract the service contract from the WAR in the Maven artifact repository during the ‘init’ phase before using the JAX-WS plugin to create a service implementation framework in Java from the extracted WSDL contract. If I didn’t like the copy approach I could probably ask wsimport to just use the URL for the contract (pointing to the Simple Service Repository’s copy of the WSDL on the application server).

The rest is plain sailing – normal boilerplate JAX-WS service implementation code. In my build I use the Cargo plugin for Maven to deploy the service implementation to Glassfish and SoapUI’s Maven plugin to run a service integration test suite during every build.

On the build server, this service is also built by Jenkins, but this time its triggered by the Simple Service Repository application being successfully re-built. That way, if the service contract for my service changes, my application gets immediately re-built and re-tested so that I’ll know if I’ve introduced a defect into the system.

In some very simple cases, the service project is so light that it only contains a few class files. Because JAX-WS can do annotation based deployment there can be very little in the way of metadata like deployment descriptors etc.

An overall view of the Simple Service Repository solution in action.

A job well done?

So there you have it, version 0.1 of the the Simple Service Repository is complete.

It’s storing my service contracts centrally, it’s making them discoverable, it’s supporting contract-first development and it’s alerting me if I introduce changes to my contracts that destabilise my service implementations. It’s even supporting simple release based versioning of contracts and data models.

To my mind it fits the brief perfectly. It’s highly available and accessible, repeatable, manageable and provides a valuable platform that supports closer collaboration between service designers and service developers.

More importantly it was very quick and easy to create. It requires zero code (if you don’t count HTML as code), it cost me about a day in development time and it draws nicely on existing low-cost open-source tools and techniques. It also requires very little infrastructure and will run nicely on a normal laptop. I could probably even put it into the cloud without too much additional development effort.

In summary, I’m still no Jedi (unfortunately) but I’m happier with my ‘DIY’ Simple Service Repository than I have been with anyone else’s.

Find out more…

Would you like a copy of the Simple Service Repository? Would you like me to open-source it?

Comment, subscribe or contact me for more information.

Demo:

You can see an online demo of my version of the repository detailed in this article by clicking on the screenshot below.

SOA Certified Architect: Module 1

Fundamental SOA and Service Oriented Computing.

In the past few weeks I’ve been studying hard in order to take my first SOA Certification exam.

The certification programme that I have chosen to study is from Thomas Erl’s SOASchool and is (to me) undoubtedly the best in the industry. I say that for a number of reasons…

1. It’s totally independent and completely vendor-neutral (as all good SOA should be).
2. The content is thorough, proven and impeccably researched.
3. It’s practical and based on cutting edge policy’s and best practices.

Of course, I understand that certification is not for everyone, but in my case I felt that because SOA is surrounded by so many myths, legends and falsehoods, it probably makes sense for me to add a quality mark to my work so that clients can be confident that the challenges I often encourage them to tackle are based on a well thought out combination of very thorough research and hard-earned experience.

The full certification programme will take me many months to complete. It consists of 5 course modules each consisting of home study presentation booklets backed up by audio CD’s, books (recommended but available separately) and sample exam-like question cards.

The course content is very thorough and of a high quality. All the major SOA topics are presented well and cross-reference throughout (so you get a good impression of just how interconnected all the topics are and how well thought out the whole certification programme actually is).

This first module and associated exam covers the fundamental topics of service-orientation at a high level. It covers the origins of SOA, strategic benefits, SOA terminology, adoption impacts, technology choices, industry maturity, design approaches and project delivery options.

The exam itself is administered by Prometric, takes about an hour to complete and is surprisingly taxing. 80% of the answers need to be correct to achieve the required pass rate.

Conclusions.

Overall I found the whole experience worthwhile and very enjoyable. I achieved a very good grade and already I feel much better equipped for future boardroom discussions even though I’ve only completed one module. In that sense, the course has probably paid for itself already.

It’s fair to say that the process wasn’t totally without fault. One of the audio CD’s didn’t work and had to be replaced, and Prometric allowed me to book an exam at a testing centre which wasn’t actually open on the day of the test.

Thankfully, the problems I did have were rectified very quickly and to my complete satisfaction. They did add some time delays into the whole process though, and it probably took me around 2-3 weeks longer than it should have done to complete the module. Luckily I wasn’t in any rush, but others may have found this aspect a tiny bit frustrating.

Introducing SOA Growers Ltd.

My new venture ‘SOA Growers‘ is dedicated to helping businesses get the best advice and support with the challenges of service-orientation.

I’ve been asked a lot of questions of late about why I think the time is right for a consultancy specialising in service-oriented architecture, so what follows is a collection of those questions and my answers.

Great name ‘SOA Growers’. Where did the idea come from?

We wanted a name for our company that allows you to instantly identify with what to what we do. SOA Growers seemed appropriate because it encapsulates our whole commercial offering in a nutshell. We help our clients to reap the benefits that strong service-oriented architectures can deliver, often starting from quite humble beginnings. Of course being based in the ‘Cyber-Orchard’, amongst the beautiful countryside of the West Country also helped with the inspiration.

What inspired you to start SOA Growers?

Service-orientation as a design paradigm has come of age. It’s managed to break its long mistaken association with web-services technologies thanks to leading industry figures like Thomas Erl who have revolutionised the way we think about service-orientation and refined the methodology to a point whereby it can be applied to award winning effect predictably and repeatedly.

Why should I use service-orientation in my solutions?

Since 2007 I’ve been applying the design rules and disciplines of service-orientation to distributed computing architectures and I’ve discovered that it’s a methodology that really works.

Service-orientation has clearly defined strategic goals that make sense for most organisations and it brings to an end the cycle of tactical system silo’s that has so dominated the IT landscape for the past 20 years. It replaces these out of date techniques with a move to more strategic service-oriented solutions that deliver greater business agility and better longevity.

When correctly applied service-orientation creates a new kind of IT environment where great business and technology alignment and long term business benefit are both expected and delivered. The design patterns, technologies and techniques of service-orientation are also very important for cloud computing, so if you want to do cloud it’s helpful to be able to understand and apply the concepts of service-orientation to your solutions.

Shouldn’t I just ask to my incumbent IT vendor to build me some web-services?

No! That’s probably the worst thing you could do. New tools and new web-services do not equal good SOA. The SOA-manifesto supports this point of view by stating that: ‘products and standards alone will neither give you SOA nor apply the service orientation paradigm for you‘. In other words, service-orientation is not something you can buy off the shelf or generate with a right-click, it must be properly crafted so that you get the full long-term benefit for your business.

So what should I do to ‘get started’ with service-orientation?

Personally I’d urge all directors and managers with a responsibility for IT projects to completely ignore the nitty-gritty technical choices of SOA in the first instance an instead concentrate on obtaining some good independent advice about service-orientation as a business strategy. That way you can get an understanding of the business benefits of service-orientation before spending lots of money on expensive technical change programmes which might not achieve the required result.

SOA Growers is uniquely placed to offer this kind of independent advise and expertise. We are intentionally independent and we can help with all aspects of SOA from policy setting through to service design, development and deployment. We understand service-orientation, but most importantly we specialise in it and have done it before with great success!

Award winning innovation with SOA and ATG

I’m pleased to announce that the Screwfix ‘Fusion’ programme yesterday won a prestigious industry award. This multi-million pound retail solution (for which I was the SOA architect) has been awarded Retail Technology Initiative of the Year 2011 by Oracle and Retail Week magazine.

So what is the Fusion programme and why did it win?

The Fusion programme consisted of 4 projects and involved over 100 people – all tasked with delivering a totally new and ground-breaking multi-channel retail sales system for sales order capture and customer service built using ATG eCommerce 2007 and supported by a bespoke service-oriented architecture.

The unique and innovative approach taken by Fusion meant that for all sales could be captured directly into ATG from all 4 retail channels – call center, stores, web and B2B. Because no traditional EPOS system was used in any of these channels, the customers resulting shopping experience could be seamless regardless of how they chose to shop with Screwfix.

Of course ATG can only go so far, so we designed a custom-built service-oriented architecture so that our strategic goals (business and technology alignment, increased organisational agility, intrinsic interoperability and vendor diversification options) could be realised.

In Screwfix’s case vendor diversification options and increased organisational agility proved particularly useful. The service-orientation approach taken means that Screwfix is free to change vendors of back-end systems at any time without the need to alter its ATG implementation. Additionally, the business agility created by having ‘business aligned’ SOA has allowed new commercial opportunities such as B2B and mobile to be brought to market very quickly.

As the SOA architect for the 3 years I spent on Fusion and the founder of the Screwfix SOA Governance Board I’m hugely proud of this achievement and I would like to extend my hearty congratulations to all my friends at Screwfix for their winning efforts!

If you’d like to find out more, please feel free to get in touch.