Improving EA's Return on Investment
Selling Enterprise Architecture to the business is not an easy task. This is largely due to two things; firstly, the prima facie business value of EA in its ‘traditional’ sense is just not there, and secondly, EA as a discipline is not fully understood by those outside (and within) the industry. Many discussions around ‘what EA is’ and ‘how to justify it’, etc are still taking place within the domain. One discussion topic at the 2012 Open Group Conference for example was titled “Why We Can't Agree on What We Mean by Enterprise Architecture” (presented by Leonard Fehskens, VP Skills and Capabilities, The Open Group, US), more than two decades after Mr. Zachman coined the phrase!
Back to my first point; what is meant by EA in the ‘traditional’ sense? Traditional EA comprises the deeply entrenched and rather expensive architecture practice within organizations performing functions such as business process modeling, application portfolio mapping, technology landscape mapping, and the like, none of which are going to be of much interest to the average C-level business stakeholder except maybe the CIO. Additionally, it doesn’t take a very large or even a very complex organization to make many of these activities completely redundant. Business process modeling, for example, can quite literally be a never ending exercise that needs to be focused with clear objectives in order to provide any real business value.
Accordingly, with the two biggest challenges with ‘traditional’ EA at the moment being a lack of understanding and the approach, how can we shortcut the return on investment (ROI)?
* Conduct an initial architecture maturity assessment of the organization. There are two main benefits of this assessment, namely; it will aid stakeholder understanding of the architecture domains (BIDAT) and goals through the assessment survey itself, and it will provide the organization with a maturity benchmark which can be used for SWOT analyses and other strategic management processes.
* Given the architectural maturity as well as the business goals, or where the organization stands to gain the most value, carry out a brief scoping exercise. Develop measurable key performance areas (KPA’s) or success areas within the project or environment. The idea is to limit the scope and therefore the timeframe for ROI.
* Carry out a brief stakeholder analysis and identify pertinent deliverables that would provide value to the project or environment. Create a backlog of requirements and associated deliverables with strict timeframes for delivery.
* Interview stakeholders for feedback and assess identified KPA’s and highlight areas of improvement.
Depending on the architecture maturity of an organization, an Agile approach to EA lends itself aptly to the above points. An Agile EA approach would entail an initial stakeholder analysis, a defined and visible backlog of user stories (architectural artefacts and the requirements behind them, i.e.: the ‘why’) and two week cycles (or sprints) for quick ROI. This shortens the lifecycle of the ‘Plan, Do, Check, Adjust’ process thereby ensuring stakeholders expectations are constantly managed and value is seen from the architecture at least every sprint.
One thing to keep in mind with an Agile EA approach is the architecture strategy and supporting roadmap. In shortening the cycle time of architectural work one may lose sight of the ‘bigger picture’ of the organization. A supporting output of the architecture maturity assessment could be a high-level architecture roadmap based on the organization's maturity and strategy. This roadmap should govern the Agile backlog and therefore the architecture development.
Change management methods such as Stop, Start, Continue, Change (SSCC) can also prove very useful for more architecturally mature organizations. This method documents things that aren’t working and should be stopped, activities that should be initiated or started, efforts that are being performed and should be continued, and things that are working to some extent but should be changed. An example of Business Architecture SSCC for relatively mature organizations could thus be as follows:
* Stop - Limiting access to architecture toolsets/ discounting the potential value of Business Architecture/ developing business architectures in isolation to the rest of the organization.
* Start - Referencing the tools central repository for reuse of Business Architecture artefacts/ maintaining live business architecture documentation/ integrating Business Architecture artefacts into the business (referencing for projects, using for personnel training)/ developing quality criteria for business architecture artefacts.
* Continue - Enforcing Business Architecture standards and driving toolset adoption/ assigning business ownership to Business Architecture initiatives.
In summary, educating business users on the potential value realized through EA need not be a lengthy technical discussion, nor does one need complex A-0 size architectural diagrams. An architecture maturity assessment for benchmarking and understanding, a short-cycle architecture approach such as Agile, and closely managed stakeholder expectations, coupled with EA positioned as an investment and not just a recommendation should get most business stakeholders interested. With regards to the more mature or established architecture practices, a more proactive approach in adopting continuous improvement or ‘architecture kaizen’ through Agile methods may get more business engagement and improve the ROI.