• Environmental Factors
• Large applications are complex and incorporate other applications & components.
• Need for standard interfaces and products
• We continually need to accommodate change, and a review of our infrastructure each time we need to make a change is cost and time prohibitive
• System design modifications & upgrades now are needed on weekly or monthly schedules
• We are finally building applications that we expect to change, and need to have a solid, well thought out foundation on which to build them

Expected Benefits

• Improved alignment of IT solutions with business strategy
• Greater ability to set realistic IT goals
• Enhanced enterprise information sharing
• Reduced software and data redundancy
• Reduced information systems complexity
• Greater reliability at implementations & updates
• Reduced dependency on key resources
• Improved accuracy in scheduling software development / implementation
• More accurate forecasting of development and support costs
• More efficient deployment of technology solutions
• Increased traceability

Tangible Benefits

• Promote better planning and decision making
• Improve communication through standardized vocabulary
• Views communicate complexity and facilitate management
• Enable strategic use of emerging technologies

It’s been a long time since I wrote part 1, but I’ll try to get the next few parts out asap.  If you recall, I was writing about the purpose and reasons for Enterprise Architecture. Along with planning and strategy, execution is critical.  We must create and tailor

Part 1 of 5 part article…

The primary purpose of an Enterprise Architecture (EA) is to inform, guide, and constrain the decisions for the enterprise, especially those related to IT investments.

The true challenge of enterprise engineering is to maintain the architecture as a primary authoritative resource for enterprise IT planning. This goal is not met via enforced policy, but by the value and utility of the information provided by the EA.

In general, the essential reasons for developing an EA include:

• Alignment—ensuring the reality of the implemented enterprise is aligned with management’s intent

• Integration—realizing that the business rules are consistent across the organization, that the data and its use are immutable, interfaces and information flow are standardized, and the connectivity and interoperability are managed across the enterprise

• Change—facilitating and managing change to any aspect of the enterprise

• Time-to-market—reducing systems development, applications generation, modernization time frames, and resource requirements

• Convergence—striving toward a standard IT product portfolio as contained in the Technical Reference Model (TRM).

Selling EA vs. Building Support

The single most difficult task in delivering and developing and Enterprise Architecture program is gaining support from the enterprise itself. This is why I was so passionate about writing this report. There are many bumps and detours along the way, and if we all can avoid and maneuver them, EA will advance as a whole and become more accepted and understand.

There is little reason to start an EA program itself unless it is supported by the business and treated as a business initiative. It will require executive level commitment and persistence. The IT department should not have to continually go to the well in various user organizations to get their support if there is a good plan and strategy in the beginning.

Want to read the rest? Get my Ten Secrets to Selling Enterprise Architecture and download the entire 33 page article.

** Note – As of Jan 1 2009, this report is no longer available publicly.  If you want the details, go to our Membership Portal **