SmartAdvice: Link Business Units With Common Architecture
Empower your company with a defined enterprise information architecture, The Advisory Council says. Also, the pros and cons of using software and hardware emulation tools; and a review of network architecture means taking the big-picture view.
Editor's Note: Welcome to SmartAdvice, a weekly column by The Advisory Council (TAC), an advisory service firm. The feature answers three questions of core interest to you, ranging from career advice to enterprise strategies to how to deal with vendors. Submit questions directly to email@example.com
Question A: How can we develop an enterprise architecture across disparate business units?
Our advice: Attempts to define enterprise architectures can become political nightmares if what you really mean is "How do I get everyone to use the same operating system?" Conversely, if you recognize that policy and organizational decisions are paramount, and that technical decisions are derivative, then an enterprise information architecture can empower your company in dramatic ways.
Preparing The Soil
It may already be too late, but ideally there are some things you want to nail down before you make a management commitment to defining an enterprise information architecture:
Define your terms. First, what does disparate mean? CBS in 1970, with the CBS Television Network, Columbia Records, Fender Musical Instruments, and Creative Playthings, had truly disparate divisions, in the sense that their products were wildly different, their target markets and sourcing vendors were different, their business models were different, and their cultures were different. Compaq in 2000 might have had different products (PCs, Intel servers, Alpha servers, storage), but their target markets, sourcing vendors, engineering methodologies, and cultures were much the same.
Second, what does enterprise information architecture mean? We suggest that any IT architecture is simply a formal specification of how a computing solution will be organized, characterized by decomposition of the problem into components, with clearly defined interfaces among the components. We suggest that an enterprise architecture is an IT architecture that addresses all the computing of the enterprise, and which subsumes other IT architectures.
Secure your political base. Specifically we mean "Make sure the CEO knows what you're trying to do and why, and that he or she agrees with the attempt."
Do your homework on portals and collaboration software. These may be new elements to your colleagues and you need to be several chapters ahead.
Pick an inclusive task force. Don't pick only super-techies. The tough issues will be organizational and strategic. Include the most likely nay-sayer.
Decompose top-down. We suggest a top-level decomposition of enterprise computing into a collaboration architecture, a reporting architecture, and an operational systems architecture.
Start with collaboration. Since that architecture includes E-mail, an office application suite, browser technology, and desktop and laptop standards, you've probably got most of the architecture already agreed on. The only new elements are portal technology and collaboration software.
Move second to the reporting architecture. We have in mind here a standalone executive resource which uses a relational or multidimensional data store and powerful reporting tools to support a) real-time display of key performance indicators and alerts, b) ad hoc reporting, and c) sophisticated trend analysis and forecasting.
Move last to operational systems. Having been fairly strong about standardization on the first two, you can display some flexibility here. As you decompose operational systems (into marketing, engineering, etc.) you may find good arguments for noncommonality. They typically come from three sources:
Substantially different classes of work;
A "perfect" purchased application package that only runs on one system; and
A "life-and-death" requirement for 24-by-365 computing.
You don't need to fight this non-commonality if you do the next step right.
Define the interfaces among your architectural components. How do engineering systems talk to manufacturing systems? How do sales order-entry systems ship results to the reporting system? How do forecasting systems present files to the collaboration architecture for collaboration up and down the supply chain?
Here's where you get to have the .Net versus Java 2 Enterprise Edition fight. Drive for one network standard, one messaging protocol, one application integration architecture, one common resource for message content and format translation. "The Internet is the network" is a starting point that defuses a lot of contention.
2014 Next-Gen WAN SurveyWhile 68% say demand for WAN bandwidth will increase, just 15% are in the process of bringing new services or more capacity online now. For 26%, cost is the problem. Enter vendors from Aryaka to Cisco to Pertino, all looking to use cloud to transform how IT delivers wide-area connectivity.
The UC Infrastructure TrapWorries about subpar networks tanking unified communications programs could be valid: Thirty-one percent of respondents have rolled capabilities out to less than 10% of users vs. 21% delivering UC to 76% or more. Is low uptake a result of strained infrastructures delivering poor performance?