Archive
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.
Coming Soon: Book Review ‘SOA with Java’
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.
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?
