This Blog Has Moved to Forrester

Please continue to follow this blogger at blogs.forrester.com/brian_hopkins. Same material, new location. See you there!



Showing posts with label Governance. Show all posts
Showing posts with label Governance. Show all posts

Friday, January 21, 2011

The ‘Order-Deliver’ IT Model is Broken

The current IT Delivery model will not support tomorrow’s competitive environment.
It simply takes too long. While the Business is “ordering” and IT is “delivering”, another more nimble competitor has pulled their business partners into the kitchen and prepared a better dish, together, in half the time. 
Over the last five years, practicing EA has provided a front row seat to some serious shifts in corporate thinking driven by two factors:
  • Economic meltdowns that reinforced the balance sheet’s importance. Shareholder equity = Assets - Liabilities. That’s an easy formula that will not change with technology. How much equity and therefore value a company has will always be dependent on the decisions it makes about managing assets and liabilities for the greatest return. If you need an example, look no further than the housing crisis. Many of the greatest investment banks were ruined because their liabilities (shaky mortgages they helped lending institutions underwrite) far exceeded the long term asset value. This lessons still reverberates in the minds of CEOs everywhere, not just the financial sector - the business case for investment must make sense and IT is no exception.
  • Big, “Enterprise” solutions weigh heavy on corporate profits - now a new technology wave is coming. Since about 2000, large corporations have been investing heavily in big, enterprise systems that automate and optimize core business functions. Vendors have supported industry vertical solutions by a “mix/match/customize” approach, with lots of professional services for each dollar of software sold. These investments, funded with heavy capitalization, are now showing up as depreciation on corporate balance sheets. While companies pay off these large capital procurements, a new generation of technology is emerging that can collect a data from the environment with new sensors and process this ‘Big Data’ with next generation Business Intelligence in highly specialized, industry vertical solutions. The Cloud has emerged to allow much of the required technology to be rented in a pay-per-drink model, making large capital commitments a thing of the past.
It’s cliche, but true - the only constant thing is change. How well we adapt to it is what determines our survival.
The 80/20 Rule Applies
The 80/20 rule suggests that big, capitalized, enterprise technology investments are diminishing in importance. Most companies have made the 20% investment that gives 80% of the benefit, and investing more for diminishing returns doesn’t make sense. What does make sense? Building out process automations with new, “smart” technologies to measure, analyze, predict and react with great speed and agility. Vendors are beginning to offer highly specialized solutions that solve critical, industry specific problems and require little in terms of long term capital commitment. Add in the Cloud, with a pay-per-drink pricing model, and buyers will be able to ‘opt out’ of solutions that do not meet expectations. Things indeed will be different.
The New Order  - Innovation, Agility and Accountability
If the old model is broken, what new one will emerge? Three characteristics define it:
  • Innovation. Innovative businesses that can adapt their thinking to the new environment will adopt emerging technology to solve “unsolvable” business problems.
  • Agility. Business that can experiment, fail fast and quickly redirect to the right solutions will out pace their competition.
  • Accountability. Good decisions must be rewarded, and good accountability means both clarity in who gets to say “yes” and then tracking and tying the results back to executive performance.
Each of these is perhaps its own separate blog, which I will save for future posts. I conclude with a thought that summarizes EAs best role in this new model - we must become the facilitator of good business decisions by 1) understanding our business and the potential of emerging technology, 2) clearly defining the impacts of both good and bad architecture decisions and 3) enabling business ownership and shared Business/IT governance of technology investment decisions. 

Monday, October 11, 2010

The Essential EA Toolkit Part 3 - An Architecture Governance Process

The Essential EA Toolkit is a four-part blog on some recommended tools for Enterprise Architecture Teams. By "tools" I mean a few well-executed deliverables or processes that contribute enormous value to the organization (read Enterprise). These are not technologies; they require only standard office productivity software and perhaps a collaboration application such as SharePoint.

The Essential EA Toolkit (Part 1) identified the following four items:
  • A Business Capability Model (see Part 1)
  • A Standards Repository based on a Reference Architecture (see Part 2)
  • An Architecture Governance Process
  • A Strategic Blue Print and an Enterprise Roadmap.
This post examines the third - an Architecture Governance Process. In last week's posting I presented a definition of IT Governance:

"Specifying the decision rights and accountability framework to encourage desirable behavior in the use of IT."
- Weill, P. & Ross, J. W., 2004, IT Governance: How Top Performers Manage IT Decision Rights for Superior Results", Harvard Business School Press, Boston.

Governance is an essential function of Enterprise Architecture. An Architecture Governance Process is the set of activities an organization executes to ensure that decisions are made and accountability is enforced during the execution of it's architecture strategy. An effective EA Governance process institutionalizes decision making and ensures accountability for decisions related to this. The Enterprise Roadmap, lays out the strategy, while the standards establish the building blocks used in execution.

The extent to which this definition differs from IT Governance depends on the role of EA in the organization. For most, the term "Enterprise Architecture" still implies "Enterprise Technology Architecture", therefore EA Governance is tactical and narrowly applied to conformance checking against technology standards. In a growing number of companies, EA is gaining ground as a strategic activity and therefore EA Governance is broad and approaches or exceeds the scope of IT Governance.

Here are two examples -

Example 1 - Tactical EA: An organization has established an Architecture Standards Repository and filled it with content specifying technology product configuration, application development and data management standards. The governance process specifies how projects and infrastructure services are checked for conformance, how they are approved, who gets to make exceptions decisions and under what conditions.

Example 2 - Strategic EA: An organization has just completed delivery of an Enterprise Roadmap in partnership with the business. The roadmap lays out the technology investment strategy for the next 18 months, identifying the programs and projects the business intends to invest in and how those investments build out the enterprise's architecture.

Governance process establish the checks, accountability and decision points to ensure that investment dollars execute against this roadmap and the future architecture is achieved. How will the organization identify deviations? How will they be handled? Who approves these? How will changes be communicated? Who is accountable if changes lead the organization astray?
Both examples are valid approaches and depend on how an organization defines Enterprise Architecture; it is therefore critically important to effective governance that an organization have a definition.

Here are  three components of effective EA Governance. The first two are commonly recognized as being part of "EA", while the third is an EA function in a strategic sense but is not solely owned and executed by traditional EA teams.
  • An Architecture Review Process
  • A Standards Management Process
  • A Roadmap Management Process
An Architecture Review Process -

This process establishes periodic reviews of solutions at various points in the technology delivery lifecycle and proposes changes to the body of architecture standards. It is tactically focused; with the objective of ensuring conformance to strategy and standards, identifying exceptions, and documenting issues with enterprise impacts.

Most mature architecture organizations have some form of architecture review, however some overlook a fundamental benefit - review provides a chance to educate and seek consensus.
In these organizations, review is conducted purely by a team of "architects" who scrutinize the documentation and pass or fail it via an Architecture Review Board (ARB). This practice, while it can be effective, promotes an ivory tower perception and estabishes an "us/them" relationship between architects and the rest of IT.

A better practice is to have broadly attended Architecture Review Meetings to communicate, promote understanding of and answer questions about a proposed architecture. Invite managers and working level technologists from infrastructure, development, security, testing, and of course architecture. Out of the meetings document issues such as potential deviations from or gaps in standards; also identify enterprise dependencies.

With plans to resolve issues in place, architecture approval can then be sought by an ARB consisting of executives from the various IT departments - not just architecture. Since these executives and their subordinates were invited to the Architecture Review Meetings, there is no need to rehash details of at ARB. Instead, only the issues are discussed and approval is sought to move forward if items remain unresolved or exceptions exist.

In addition to being more collaborative, this approach promotes ownership of the architecture broadly across the IT organization and establishes clear accountability for proceeding via an executive-level ARB. In addition, it improves participation in the process because people's time is more effectively used. Working technologists can attend the review meetings, then brief their executives on issues at the ARB prior to vote.

Since a primary purpose of the Architecture Review Process for most technology-oriented EA practices is evaluation of solutions against enterprise standards, the next governance process manages those standards.

A Standards Management Process -

The Standards Management Process establishes change control over architecture standards (see The Essential EA Toolkit Part 2 - A Reference Architecture and Standards Repository). It defines how an organization tracks deficiencies and gaps in its body of enterprise standards and methodically works toward improvement.

While the Architecture Review Process is about review of solutions and changes in the standards; the Standards Management Process is about controlling the change process and communicating the impacts.

A good standards management process -
  • Identifies and documents enterprise standards that need or present an opportunity for improvement.
  • Assigns accountability and responsibility for improving the standards.
  • Takes input from and proposes changes to technology and business components of an Enterprise Roadmap.
  • Measures and reports against changes to determine effectiveness.
A Roadmap Management Process -

A final element of effective EA Governance is managing change against the Enterprise Roadmap. I consider this an EA process even though it is not entirely owned and executed by the EA group (depending on the organization's definition of EA.) In many IT shops, management against strategic assets such as a roadmap is the function of a business strategy and planning group. This team is, in a broad sense, part of the organization's EA function, whether so named or not.

I tweeted recently, "Having a roadmap is only half the battle. Executing to it and managing change against it is equally as tough!" I was surprise at the number of retweets, indicating that this is on people's minds.

An effective roadmap management process has several elements. First, a clear definition of what the roadmap is and is not is essential; creating this definition can be tough. Is the roadmap a PowerPoint presentation? Is it the underlying data about the proposed investments and technology landscape? Is it statements about strategy and desired outcomes made in other communications?

Once the contents of the roadmap have been defined, components that will be controlled, Rules about how changes are made and who approves them must be clearly documented. The Roadmap Management Process helps set expectations, promoting continued business and IT partnership through transparency. Without it, the benefits of the roadmap quickly vanish as uncontrolled changes make the roadmap irrelevant and governance impossible.

In conclusion, governance is an essential EA function. It ensures strategic alignment of projects and assists in achieving technology goals by enforcing and managing exceptions to standards. Two essential elements of Architecture Governance that are traditionally viewed as EA functions are an Architecture Review and a Standards Management Processes. Roadmap Management is a crucial part of governance as well. I assert that developing and managing the roadmap is an Enterprise Architecture function, even though it may be owned and executed outside of the traditional EA team, hopefully in partnership with IT strategy/planning and the business.

Next I will conclude this series with the final, and in my opinion, most important tool - an Enterprise Blueprint and Roadmap.

Share

About Me

My Photo
Brian has 21 years of engineering and technology leadership including 12 years as an IT professional. As an Enterprise Architect, Brian has been a leader in establishing Enterprise Architecture Practices in both the Financial Services and Defense industries. He has led the development and implementation of information management strategies, established architecture governance processes, and led multimillion dollar, multiyear program teams. In addition, Brian has extensive experience with web interoperability and data exchange standards established by the W3C and OASIS.