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.
Oracle’s recent acquisitions of BEA and SUN along with their own in-house enterprise middleware developments have enabled Oracle to create a comprehensive suite of products capable of supporting most long term SOA programmes.
Gartner’s latest Magic Quadrant places Oracle in top position for the ‘ability to execute’ (i.e. the ability of the products in the suite to deliver on their promised SOA functionality). IBM and Microsoft also do well, with IBM doing slightly better for ‘vision’ but slightly worse for ‘ability to execute’.
From experience this first place result for Oracle feels justified to me.
Oracle have a very comprehensive SOA suite, albeit with some migration and upgrade issues due to the rapid pace at which the suite has been growing. IBM’s second place fairly reflects Websphere’s over complicated installation and integration process which has often prevented even IBM’s own consultants from delivering the full set of benefits and features promised by their offering.
You can find InfoQ’s brief article on the report here.
If you’d like more information yourself, you can read a full reprint of the Gartner report “Magic Quadrant for Application Infrastructure for Systematic SOA-Style Application Projects“ here.
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.
To download a copy, just click on the thumbnail above.
Packt Publishing have asked me to complete a review of two of their new technical books. Subscribe now to be notified when they appear on the blog.
Service Oriented Architecture with Java is for Java programmers or architects who are interested in implementing SOA concepts in their applications and covers creating Web-services using Java frameworks.
GlassFish Security is for application designers, developers and administrators who work with GlassFish and are keen to understand Java EE and GlassFish security.
I’ve been impressed by Packt’s books in the past, so I’m looking forwards to reviewing their latest offerings.
Incidentally, Packt’s “Business Process driven SOA with BPMN and BPEL” book is an excellent read. It’s the first book I’ve read on the topic of BPMN that covers the subject cleanly, concisely and accessibly whilst clearly stating why BPMN and BPEL don’t yet work comfortably together. Anyone intending to practice Business Process Modelling using the BPMN notation or planning to change BPMN models into BPEL should get this book.
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?