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 not plugged into the news continuum that is the Internet, it may be news to some that last week Google has announced that it is to stop its collaborative tool Google Wave.
According to this Google post they had the following to say…
We have always pursued innovative projects because we want to drive breakthroughs in computer science that dramatically improve our users’ lives. Last year at Google I/O, when we launched our developer preview of Google Wave, a web app for real time communication and collaboration, it set a high bar for what was possible in a web browser.
They go on to say that ….
We were equally jazzed about Google Wave internally, even though we weren’t quite sure how users would respond to this radically different kind of communication…
…But despite these wins, and numerous loyal fans, Wave has not seen the user adoption we would have liked. We don’t plan to continue developing Wave as a standalone product, but we will maintain the site at least through the end of the year and extend the technology for use in other Google projects like Buzz.
As a early adoptor I found it interesting and very innovative. However, early on it became apparent that it was a very technical and feature rich application that only techies really knew what to do with. If anything Wave was too far ahead of its time and perhaps had too many features that confused users.
In short, it can be described as ‘a solution waiting for a problem’. Just think if it was as good at predicting the future as keeping track of the past….
Many times innovation and failure is not a bad thing. It usually provides the impetus to spawn other ideas and solutions that find a greater and more fertile audience in other areas. Any ideas on what they plan on coming up with next?
As to be expected, the book is tutorial in structure and many demonstrations for creating Validation Rules, writing ShapeSheet formulae etc. The example code for these are all included and therefore is great for those who ‘learn by doing’ making the practical and immediately deployable examples very useful.
Download a free copy of Chapter 2 – Understanding the Microsoft Visio Object Model
Foreword: Having recently completed the design and implementation of an operational BPM Competency Centre for a Global Insurance company, I thought I would share a bit of my recent experience on the subject. The Competency Centre initiative formed part of the extremely ambitious IT and Business Transformation programme that is fundamental in redefining the organisation and laying the foundation for its expansion strategy across Europe.
Over the decades, the search for IT and/or Business ‘Excellence’ has led to a concept that is often misunderstood and can be very amorphous in definition and execution – Business/IT Transformation.
A term also commonly used in the same context is that of a Centre of Excellence or ‘CoE’ aka ‘Competency Centre.’ In this post, I will not attempt to redefine either, but rather explain a bit more about how the various constituent parts of a CoE can support Transformation projects and more specifically Business Process Management (BPM) initiatives.
The purpose of a CoE is to act as a nucleus for promoting and managing the collaboration of people, processes and technologies around key organisational objectives by ensuring the application of best practices, education and training, support services and technology awareness.
In most organisations, this is an extremely complex challenge, especially if the level of organisational maturity is low and their existing operational model is disjointed. That said, more mature and integrated organisations find the exigency and necessary focus for adopting a CoE a challenge.
…in an effort to consolidate that, we would like to combine our efforts in what will be the next generation BPM platform, called jBPM 5.
jBPM 5 will be based on the combined experience of jBPM and Drools Flow (and related projects like RiftSaw and Overlord), and will bring together the benefits of both solutions (and much more).
It goes on to say…
The architecture of jBPM 5 builds on the experience that was built up over the past few years based on our customer feedback as well as strong community involvement. It will continue the vision of all of the constituent projects, so large parts of the architecture that we are presenting here will probably not come as a surprise to you, either because it already exists in a current project or because it has been on the roadmap for quite some time (BPMN2 for example).
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.