Archive
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.
Creating Business Agility by Design.
Agile engineering practices are really good for ensuring that IT development priorities are responsive to business requirements, but they don’t necessarily deliver an agile business.
I define ‘business agility’ as ‘the ability to quickly harness what you already have to make the most of an emerging business opportunity‘.
Let’s explore that sentiment a little. How easy is it for your business to ‘harness what you already have’?
The most common problem that I see when I’m working with clients is brittle applications, applications that can’t be easily accessed, re-purposed or reused to respond to changing business demands. For example: inaccessible and intransigent fulfilment processes locked inside big ERP systems that prevent lucrative new channels from being offered to customers, or payment processes that don’t meet compliance targets but can’t be removed or replaced without breaking something important.
No matter how modern the system, or how many ‘best practices’ are used in its development, reuse often remains stubbornly elusive. Sadly agile project management practices can’t come to the rescue either. Agile development practices generally have no effect on the long-term reusability of an application one way or the other.
‘Business Agility’ = ‘Easy Reusability’
In the current climate, reuse is probably the most important non-functional requirement that you could possibly express. However, there are many competing techniques for achieving reuse in software systems so the key is to understand which techniques can really help you and which should be avoided.
I’d argue that ‘Easy Reusability’ is the result of careful interface design coupled with simple accessibility. The techniques that you use to build your software systems should reflect these goals.
Interface design should try to take into account the broadest requirements possible, with ‘future‘ use-cases given appropriate levels of consideration. Likewise, simple accessibility (or interoperability) can be achieved by choosing interface standards that will allow for easy access from a suitably wide variety of consumers.
SOA can provide a good solution.
In my experience, Service Oriented Architecture (SOA) is a good paradigm for delivering both easy reuse and business agility. What’s more, when you combine SOA with modelling techniques that encourage the identification of future reuse opportunities you can create a very powerful environment for delivering some serious business agility.
Contact me to find out more.
Ben Wilcock is a SOA Consultant working for SOA Growers Limited in the UK.
New Year, New Thinking?
2010 is over and 2011 has arrived. We’ve all returned to work ready to push on with our commitments – but can we honestly say that we are producing better software now than we were at the beginning of the millennium?
In another great article from InfoQ, two seasoned IT professionals - Bruce Laidlaw and Michael Poulin – each with more than 30 years of experience, have compared their conclusions about the past and present of IT, focusing on what we are doing to make progress.
It’s a very pro-agile article and they do cover a lot of ground. However, it’s interesting when discussing certain aspects of agile methodologies they argue that…
“[The] Majority of agile methods are based on assumption that business cannot and will not work differently tomorrow than it does today; these methods do not challenge the way business works even if this way is contra-productive for the enterprise.”
I genuinely love agile projects, but its fair to say that on some agile projects in the past I’ve also been in the situation that they describe in their article where an agile development process fails to adequately deliver non-functional requirements adequately due to a preference to deliver perceived business requirements…
“It’s not a rare situation where agile teams promise to add an error handling mechanism, escalations, notifications/alerts, compensation logic, transactional integrity, security and operational stability “later on”.
All these technical things are Quality of Service (QoS) attributes that the business expects from the technology by default, not ‘next time’ or as a special additional feature.“
The article is a pretty convincing argument for a new kind of approach to enterprise software development where business architecture, technical architecture and governance discipline combine to ’build-in’ quality and agility from the start, something that many modern developments often lack .
You can read the full article on InfoQ here.
Getting Started with BPMN
BPMN is a brilliant tool for designing or documenting your business processes, but it can be a bit daunting if you’re faced with adopting the diagramming standard quickly or within large teams.
But all is not lost – with these simple tips you can ease your adoption and see great results within a few hours.
My top tips are:
- Lead by example – get stuck in.
- Use my handy notation guide or others like it.
- Peer review models with the whole team to get consistency in your approach.
- Start with ‘as-is’ processes first, agree them, then create ‘to-be’ processes.
- Keep it simple. As a team agree, the notation shapes you will and will not use.
- Use a good diagramming tool, preferably something with team support like EA.
- Accept that diagrams are never right first time, ever, even for pro’s!
- Get proficient at diagramming first, save BPEL and other technologies for later.
BPMN Diagramming Cheat Sheet
This is my personal BPMN 1.1 cheat sheet I created in EA. I’ve put this together based on a couple of years of experience of daily BPMN diagramming within a medium sized analysis and design team. The cheat sheet contains a whole host of tips for creating basic but valid BPMN models and some guidelines on how ensure your diagrams are clear, concise and easy to understand.
Ben’s BPMN (1.1) Notation Cheat Sheet
To download a copy, just click on the thumbnail above.
BPMN – Just Do It…
I’m a big fan of Business Process Modelling Notation (BPMN) and, of course, Web Services. But it strikes me that not many companies understand the benefits of BPMN or how to approach it.
This could simply be down to the fact that discussions on BPM are often driven by big name software vendors who just want to sell software. They do this by promising a utopia of right click engineering where a BA’s efforts are instantly turned out as executable code.
But sadly this utopia usually only exists in the salesman’s demo. Doing it for real is much, much more difficult. In reality making BPMN models executable actually requires lots of tweaks in the tooling that are non-standard. BPMN is not really100% translatable into code just yet. There are bits missing, and someone has to fill in the gaps.
But bear with me on this – I still argue that its worth investing in BPMN right now, even if you can’t “auto-magically” execute these processes on a server.
My reasoning is that first and foremost, BPMN is a modelling language, so you don’t need expensive tools to create a process model and get business benefits from it. UML sets a precedent for this argument. UML allows us to refine requirements and designs, but it was rare in practice for UML tools to generate executable code (and vice versa) even though there are plenty of tools that support this feature. The value of UML was in the model and the communication it facilitated between collaborators.
The truth is, executing BPMN may not be important just yet – no matter what the tool vendors say.
I’ve visited companies that do pure BPMN modelling without process execution and they’re very happy with the business benefit they derive from models alone. They understand that even static BPMN models have business value. BPMN describes their business processes in a standardised format that is accessible to everybody. BPMN promotes discussion and helps build consensus. In summary, BPMN facilitates business change very effectively.
Secondly, the tooling and standards are evolving rapidly. In the near future, the pain of auto-magically turning BPMN into executable processes will diminish (if you don’t beleive me check out Intalio). If you follow my advice and start building models now then you’ll have an easier time moving to those tools in future. You’ll have an established library of business processes described in BPMN and your own pool of fully trained BPMN authors at your disposal.
For more information and ideas on this subject, why not get in touch?
