Since the emergence of Business Process Management (BPM), organisations adopting it have had a wide variety of experiences – some successful and others less so. Some would argue that because BPM is so amorphous that any project is considered to be analogous to ‘boiling the ocean’ and therefore the outcomes may vary from exceptionally successful to, in some cases, disastrous.
Typical challenges that often cause concerns during a BPM initiative include:
Focus on automation supersedes process excellence and continuous improvement
Complex transformation programs end up in failures, as the business scope is not prioritised and the program roadmap not defined in advance
Traditional Waterfall business requirements & process analysis phase takes an average of 6 – 9 months with no results to show in production for at least a year and as a result, business sponsors often get disillusioned with BPM
Lack of alignment between the investments across business strategy, process improvement and automation activities
In recent months there has been a noticeable resurgence in the need for Business Architecture at both tactical and strategic levels. In my experience, there are many Enterprise Architects (EA’s) thinking about Business Architecture, but very few who are really doing Business Architecture.
The Standish Group, an IT research organisation, documents this annually and has historically found that 31.1% projects are cancelled before completion, 52.7% of projects will cost 189% of their original estimated cost and only 16% of projects are completed on-time and on-budget.
Apart from the typical Project Management and Software Delivery Governance and Optimisation improvements that can be adopted to improve this situation, a further and probably more advantageous approach would be to adopt ‘Problem Architects’.
Solution Architects (the opposite of Problem Architects) are more commonly technical specialists focused on defining a technical solution that is usually heavily dependent on ‘clear’ business requirements often formulated by users and project Business Analysts. In most cases, this tends to be an inexact science as it is often too complex, too ambiguous, and has lots of errata due to tight project specific deadlines.
“…40% of organizations now have an established business architecture program. And most of the rest are working toward creating one. For a large majority of EA teams the question has shifted from ‘When should I start my business architecture effort?’ to ‘How do I get business architecture moving?’…“
For those who are not familiar with Enterprise Architecture, you may be wondering how does it value other than the obvious i.e. ‘Modelling the Enterprise’. The short presentation below explains the concept of EA BI Reporting in a very simple and easy to understand way.
Many organisations building models in order to understand their enterprise. Different stakeholders, teams working together in central repositories to be prepared for solving future problems. This presentation is focusing on Business Intelligence (BI) for Enterprise Architecture models/projects. Most important are the impact analysis reports, what happens if an application will be retired, or who is affected if an IT centre is no longer working are just a few possible questions to answer for an EA team.
Most experienced EA teams who are implementing strategic and tactical Enterprise Architecture initiatives use a variety of tools. In my experience the ability to take the concepts explained in this presentation to ‘next level’ and ensure that reporting can be readily accessible by all is to use a robust EA platform.
I would be interested to hear how well EA BI reporting is being adopted by not just EA teams but also wider organisational stakeholder.
Admittedly, everyone has a different view on what BPM and EA is and how value can be derived from each but as with most things, real benefits come from combining individual concepts, methods and tools rather than just working with them individually on a case by case basis.
This general principle of holism was concisely summarized by Aristotle in the Metaphysics: “The whole is more than the sum of its parts”.
Reductionism in contrast, is sometimes seen as the opposite of holism. Reductionism in science says that a complex system can be explained by reduction to its fundamental parts. This sounds very much like the abstraction capabilities that Business Process Mangement and Enterprise Architecture provide.
No matter how you choose to define it, ultimately the focus should be on how both can be used to solve tactical business problems while executing a longer term strategic roadmap. But I digress…..
The BPM II conference had four vendors presenting their capabilities and approaces to how BPM & EA could be used.
Earlier in the year I posted about how EA and BPM are merging in both the practioner and tools space. This was also highlighted by evidence from reports by Gartner and Forrester.
Gartner has released their latest analysis of the Enterprise Architecture vendor market.
Their overall assessment is favourable and in summary states the following:
EA tools adoption has increased despite economic challenges
Tools vendors have increased the richness of the features and functionality of their tools sets
Merger and aquisition activity (Software AG buying IDS Scheer) has provided momentum for 2009/2010.
Most tools seem to be more well rounded and now include, modelling, business intelligence and analysis capabilities that use a single data repository.
Open source and entry level tools have emerged and are seen to be gaining acceptance and interest but it is too early to tell what type of adoption there will be by a wider audience.
There is recognition in the market that entry level and no cost offerings can pose a longer term threat to vendors. This is as a result of vendors not listening to customers and not not aligning themselves with customer needs and their associated adoption of a fit for purpose EA tool.
A recording of the recent IASA E-Summit focussed on raising the understanding of MOA….
IASA has recently identified the need for an industry level education in Model Oriented Architecture which includes related concepts of Model Driven Architecture, Domain Specific Languages, code generation, Model Driven Development, Domain Driven Design and other architectural approaches that put the model at the center of IT initiatives. Conceptually this includes any process or framework that focuses on model as more than simply text and documentation.
As a part of this E-Summit series you will hear from practiced experts throughout the industry on MOA topics and concepts. This is the type of training you and your team can only get from practicioner based organizations like IASA.
The recording can be found here (may require registration)