Enterprise architecture is the way to strategically manage a company’s investment in IT. In times of industry consolidation, mergers, acquisitions, spin-offs, drops in the stock market, and a rougher economy, IT enterprise architecture might be the first thing to take a back seat to more pressing business problems. However, this is the worst thing a company can do. At times like these, a company needs to be able to quickly realign their IT strategy with their changing business strategy (Meta – The Role of Enterprise...). If a corporation doesn't have a well documented IT strategy, as an enterprise architecture, then these changes are going to be very hard to make.
Some of the other benefits in having a mature enterprise architecture lie in several areas. First, by having a well established idea of what infrastructure is going to be needed in a company, efforts can go into building it, and building it with growth in mind. Then, as specific business applications wish to utilize this infrastructure for their needs, it is already built and ready to go. Standards are another area that, while may seem as a hindrance to some, can be enforced by having a documented enterprise architecture. When a company supports standards, especially in the IT arena, support costs are drastically lowered, allowing the IT staff to do one thing, and do it well vs. having to support a wide-variety of systems, but doing none of them particularly well (Gartner - The Unexpected Case...).
Having an enterprise architecture can also help a company retain talented staff by being able to better focus training and other employee development funds, allowing the IT staff to focus on services for their internal “clients”, reduces the number of technologies the support staff has to support (see standards discussion above), and helps better focus the employees efforts, making their job descriptions much more clear (Gartner - The Unexpected Case...).
As was previously mentioned, creating and maintaining an Enterprise Architecture is an investment for a company to make, with the payoff occurring sometime in the future. The goal is to be able to deliver the right information to the right decision makers at the right time (Meta – The Role of Enterprise...).
70% of large companies are currently too busy fighting fires, solving short term tactical solutions and not developing long-term strategic plans. Just as planning your business strategy takes a different mindset, so does developing an Enterprise Architecture. Often a company’s culture and current employees are more focused on the project at hand rather than looking at their environment from a enterprise standpoint. Because of this, simply trying to “make” your IT department think strategically will most likely fail. When Enterprise Architecture is run as a program, with dedicated staff and an on-going review of the plans, a corporation is much more likely to have the efforts supported and accepted by the business and IT staff (Meta - Running Enterprise Architecture...).
Once the architecture is defined, then individual business units merely have to see where they “plug-in” to it to get their work done. For example, if the architecture plans says we are going towards a unified ERP solution, such as SAP, and a business unit wants a payroll system, maybe looking at SAP is a good start. Or if Unix systems are the “standard”, then that part of the design is already done. Finally, if the architecture defines that employee portals are important to the company to boost productivity, then a project to put a portal component together will be approved much faster than a standalone system would.
Having an Enterprise IT Architecture is also a valuable tool in reaching the 2nd and 3rd level of the SEI's Capability Maturity Model where the model calls for repeatable tasks and a defined organizational mission (Cecere). An Enterprise Architecture forces an organization to document their IT plans and align them with the business needs. Once the plans are in place, and standards are set, it is much easier to use the same methodologies, if not the same technologies to deliver business solutions. Business leadership is critical in making this move, and with enough committment, a well defined archiecture can easily push a business to the next level on the SEI model (level 2 or 3) (Meta - Enterprise Architecture Process...).
Architectures are not set in stone. However, if a business case is made for something that deviates from these standards, these plans are not show stoppers, merely a reason to stop and think about it. It is this "stopping and thinking" that shows where an Enterprise Architecture adds value. It gives the IT decision makers a baseline of the current and future environment so they can decide how (if at all) this new project fits into their architecture plans and how well it will work as the plans mature. It is up to management to decide whether or not to pursue this deviation from the standard. Or perhaps it is a signal that the standard needs to be revisited. Again, as was previously mentioned, the architecture plans need to be flexible enough to allow these kinds of changes as the technology and the business also changes.
