The Winchester Mystery House in San José, Calif., is infamous within IT circles as a metaphor for how not to grow your technology enterprise.
The 160-room mansion took heiress Sarah L. Winchester 38 years to build and draws tourists with its many architectural oddities, including staircases leading to nowhere. When your business users lament that "IT is a black hole" or "We have multiple versions of the same truth," be aware that a Winchester is under construction.
One of the best ways to avoid such a fate is to build a solid
CIOs of other midsized companies argue that an EA is something only big enterprises can create or afford. As a CIO of a midsized firm, I'd like to demonstrate how wrong that perception is.
Over the past three years, I've built an EA with an IT staff of 50, and the results have been rewarding.
First, let's eliminate some of the mystique concerning an EA, which is basically a framework for defining and describing applications, data and technology, and for ensuring long-term IT viability.
Just as a project management methodology helps deliver projects, an EA is a framework to deliver IT. Instead of making this a multiyear project with a hefty price tag, midsized enterprises can take a more pragmatic, lightweight approach. To that end, consider the following steps.
Define the scope. An EA has three main components: application architecture, data architecture and technical architecture. The most practical approach is to choose one component to address first. At my company, we chose to address the application architecture first; but my team is busy and didn't have the bandwidth to do so. So I contracted with an enterprise architect I'd worked with previously. In three weeks, we completed our application architecture, which had integration, presentation and application layers.
- Focus on business drivers, goals and metrics. An EA must link directly to your business strategy and goals. In our business, time to market is crucial, so I had to ensure that the architecture we designed could support this objective. We didn't have the option of meeting with all our executives to validate the strategy and goals. Our main sources for this information were company presentations and meetings with the CFO. Ultimately, we defined 12 business drivers, plus supporting goals and ways to measure them. For example, one business driver was "time to market," and its business goal was "to reduce time to implement business changes." We measured the result through improved response times.
Establish your guiding IT principles. I hosted a half-day meeting with the five brightest minds in IT to identify the linkage between the business drivers and goals and our own IT principles. Limit these principles to roughly a dozen; any more gets overwhelming. One of ours, for example, was "All applications must support single sign-on via Microsoft's Active Directory Services."
Draw a picture for the organization. Communicate your architectural vision through graphics that your business colleagues can grasp readily. Minimize the number of presentation slides to 10 or fewer, and cover the current and future state of your architecture. Then lay out your principles and the steps needed to get there.
Once my group was ready, I hosted a meeting with the CEO and his staff to get buy-in on our architecture. Our executive team now understands that we won't adopt technologies that don't conform to our principles, and proposed projects won't be approved unless they conform to the future-state architecture. Every year, we revisit our enterprise architecture.
We're making sure that whichever IT staircases we build actually end up somewhere.
Tony Young is CIO at Informatica Corp. in Redwood City, Calif.