By Bart Kaplan
Corporate IT departments find themselves in a paradoxical position entering 2015. On one hand, the outlook for IT budgets hasn’t been brighter in a long time. According to advisory firm CEB, IT spend is expected to rise 3.3 percent this year, the most since before The Great Recession.[1]
On the other hand, the expectations of IT organizations have never been greater. Some three-quarters of company initiatives depend on technology to one degree or another. If central IT can’t meet demands for greater speed, agility, and cost-effectiveness, business partners will procure their own solutions, spurred on in part by the falling prices and increasing maturity of cloud and Everything-as-a-Service (XaaS) offerings from third-party vendors. According to Gartner, 35 percent of technology spending is expected to occur outside the central IT organization this year,[2] led by Finance, Human Resources and Marketing departments.
The challenge faced by IT is that in addition to myriad new business projects, they must also attend to legacy technology systems and environments. These uninteresting yet critical “keep the lights on” activities suck up close to 60 percent of IT budgets.[3] That number is coming down, but not fast enough to accommodate for all the technology requests from various parts of the business.
One way IT can square this circle is by making better use of reference architectures (RAs), some of the most scalable and cost-effective tools in the IT toolbox. Among developers, however, RAs don’t have the most stellar reputation. Commonly heard complaints are that they are difficult to understand, hard to adopt, and often out of date.
What exactly are reference architectures? They are much more than pretty pictures. It’s easier to think of RAs as a kind of ecosystem of resources rather than any one thing (see figure below). Their ultimate purpose is to help solution delivery teams make better design and technology choices. At a time of exploding “shadow IT” and changing IT paradigms, the need for effective RAs is more important than ever.
Figure: Reference Architecture Toolkit
If done right, RAs can deliver substantial benefits to both IT and the business. One large financial services organization I worked with saw infrastructure standardization increase from 30 percent to 70 percent, and delivery times decrease by 75 percent, over a two-year period. By some estimates, RAs can reduce IT budgets anywhere from two percent to upwards of 15 percent.
The most mature practitioners take the following five steps to ensure their RAs are successful.
- Manage reference architectures across their entire lifecycle. Most of the focus typically falls on the build phase. But the ongoing maintenance of RAs, and eventual decommissioning, are critical to their usefulness, especially in fast-changing areas like mobility and cloud.
- Evaluate reference architectures as a portfolio. Many RAs are developed in a reactive, one-off fashion. In order to make the best use of limited resources and maximize benefits, reference architectures should be viewed holistically, using formal criteria to evaluate and prioritize them. Those criteria should be revisited over time, as capabilities grow and business needs evolve.
- View reference architectures as brands. To achieve greater RA adoption, it’s essential to consider reference architectures from the customer’s perspective. They should be easy to find, understand, and use―which in most cases they are not. By putting a consumer lens on RAs and viewing them more as individual brands, some of the most common adoption barriers can be avoided.
- Include implementation advice. RAs are most frequently owned by enterprise architecture (EA) groups, whose focus tends to be on higher order elements such as principles, standards and patterns. But without decision guides, prototypes and reusable source code―all of which make these higher order resources easier to implement―the chance that RAs get instantiated in actual solutions is low.
- Federate RA ownership. One of the reasons why EA groups fail to develop prototypes and provide source code is that their resources are limited. But responsibility for RAs need not―nor should not―reside in EA groups alone. Rather, ownership should be distributed out to subject matter experts across the organization. This will increase buy in, and substantially expand the capacity of the organization to build and maintain a full RA ecosystem.
[1] CEB Press Release, 11/17/14: http://ir.executiveboard.com/phoenix.zhtml?c=113226&p=irol-newsArticle&ID=1990182
[2] Gartner, Inc. “Predicts 2014: Application Development.” Brian Prentice, David Mitchell Smith, Andy Kyte, Nathan Wilson, Gordon Van Huizen, and Van L. Baker, November 19, 2013.
[3] Ibid, Footnote #1
Bart Kaplan is a business solution strategist with VMware Accelerate Advisory Services and is based in Maryland.
