Showing posts with label Design Authority. Show all posts
Showing posts with label Design Authority. Show all posts

Monday, May 14, 2012

African Sun Shines on the New Silos

I am sitting in the african sunshine supposedly having a month off work. However I suppose looking after grandchildren was never going to be a cakewalk! But one of the real benefits of taking time away, even if it's not a vacation as such, is that one gets time to sort out issues that have been bubbling away over time. The first is my PC configuration. Thank goodness, after just a few dedicated hours I will be much more efficient. The second one is documenting my thinking around architecture coordination in the delivery process.

I wrote a research report on this in April last year titled The New Silos [1] exploring the gaps between disciplines and suggesting a governance approach to establish cross discipline coordination. However my consulting experiences over the past 18 months have a) reinforced my opinion that this problem is pervasive and b) allowed me to refine my thinking and develop more robust solutions.

The issue that I come up against repeatedly is the inability of organizations to coordinate execution of of architecture, business strategy, business analysis and application delivery that optimizes the divisional and enterprise business outcomes. Examples of anti patterns I constantly observe include:
- business driven projects that select a major COTS product as pretty much the first action, that then drives business design and delivery in isolation of core enterprise goals (and creates a new silo).
- business users define requirements on the basis of changes to existing applications (that perpetuate existing silos)
- legacy applications are modernized by replacing existing systems with new technology without rearchitecting scope (that perpetuates existing silos)
- long project delivery timescales are addressed by concurrent release management (which increases product version and management complexity and cost, and generally fails to reduce overall functional delivery timescales)
- long project delivery timescales are addressed by agile development projects (without adequate enterprise architecture governance)
- frustration with all of above prompts business management to outsource arbitrary units of scope (which frequently creates new silos)
- frustration with all of above prompts business management to outsource to cloud provider (which frequently creates a new silo)
- enterprise architecture functions fail to show business value of broader perspective (and are bypassed by business and development)

The image below shows the coordination framework I draw to illustrate how we can address the above issues.

The framework infers (and requires) some really important policy changes:

1. Business strategy must be sufficiently understood to allow key questions of standardization, differentiation, capability independence and requirements for future agility to be applied to individual business problems
2. Enterprise architecture must link the business value of portfolio actions (from 1) with clear architecture direction.
3. Business requirements must be established as functional and non functional business models that are independent of applications
4. Demand management must break the linkage between business problems and delivery projects by consolidating similar requirements into clusters of services, components and solutions and determine opportunities to progressively rationalize the existing (legacy) portfolio
5. Programs or Projects must only be chartered once the problem is understood and the optimal service and solution architecture identified
6. The coordination activity itself requires governance to ensure stakeholder goals are met and to set governance criteria for delivery governance.

In my work over the last 18 months I have advised several very large organizations to establish a Design Authority (DA) as a key mechanism to manage the coordination. The DA should be made accountable for interpreting business priorities, transforming business requirements into delivery clusters of architecture work, services, processes and implementation components. The DA should be organized as cross functional, multi level (including exec level) and sufficiently empowered to make difficult decisions. Because, difficult decisions WILL arise. Stopping and restructuring critical business programs can be highly emotive, and the DA will need to be sufficiently strong enough to make recommendations that will be very difficult.

It constantly amazes me that most organizations don't yet operate in this manner. Of course culture, politics and career protection all militate against "radical". Yet in my experience, effective coordination of these critical perspectives will deliver real business value concurrent with dramatic reductions in complexity, cost and delivery times.

[1] Beware The New Silos! CBDI Journal April 2011