Historically, little thought has been given to creating or maintaining strategic architectures for business enterprises. As the competitive CO-architecture landscape continues to put pressure on organizations to be more efficient, the process of implementing unified Enterprise Architecture will become an essential part of any business. This paper covers the definition of Enterprise Architecture, provides a description of how it should be utilized to tightly couple business processes and goals to information systems, and how to create an architecture that is able to be supported.
Enterprise Architecture:
Enterprise Architecture is a tool that aids businesses by allowing managers to see and think about smaller functions within the whole of the business. A common phrase used to describe an Enterprise Architecture is a set of “living documents” that are short, simple, and easy to understand. Enterprise Architecture is a relationship between processes and goals that allow businesses to organize, assess, and implement changes based on a set of “blueprints.” These blueprints vary based on what is needed. For example, a company setting up an Enterprise Architecture could have three, four, or five different sets of blueprints for various reasons, such as one for product assessment, one for consumer reports, and so on. Not only is Enterprise Architecture a set of blueprints, it is the actual work behind those plans. Implementation is required for the architecture to be built and maintained, as all the plans and actions must be integrated so that proper managers can view needed material in its relationship to other factors.
After building upon the blueprints and integrating all the processes and goals, the proper questions may be asked. These questions are what bring about change that may improve and maintain a business.
An Architecture Cycle:
When establishing an Enterprise Architecture, all aspects need to be incorporated into one place. It is this assimilation that allows managers to begin questioning. Often, this process is a cycle with four phases. First, an architect receives input about new strategies, goals, and processes that may not be performing properly. Next, the architect must look at any further implications and connect those to the received input. Third, the architect makes alterations based on the input and wider implications. Lastly, the process starts all over again. Overall, this cycle gives the architect the opportunity to assess all areas of the business, including some that may have been overlooked, and make changes that will best suit the organization.
Organizing Business Processes and Informational Systems:
Once organized, an architect will assess the alignment of business processes to informational systems. Simply put, an architect translates the information that is transferring from process to applications and vice versa. The architect determines if the results are in-line with goals, and so on. Proper organization allows the architect to translate and even determine where translation is needed.