Enterprise Architecture and Business Process Integration - Assignment Example

? School: Topic: ENTERPRISE ARCHITECTURE FINAL EXAM Lecturer: ENTERPRISE ARCHITECTURE FINAL EXAM As a discipline, Enterprise Architecture may be seen as an operating logic that defines or identifies the operating model that a company or organization uses to represent its organized complexities of people, process and technology (Paras, 2005). In effect, Enterprise Architecture sets a paradigm of homogeneity through the operating model for the company to clearly determine its desired state in which business process integration and business process standardization should take place (Weill, 2007). For the said paradigm of homogeneity to take place in the running of the Enterprise Architecture, it is important to have key deliverables in place. These deliverables are tangible tasks that must be performed to ensure the successful implementation of the company’s operating model (Schekkerman, 2004). There could indeed be as many of these deliverables as possible but classifying them is also possible. Classifications could bring about key deliverables such as road maps, made up of technology, process and people road maps; application portfolio management; IT risk management; standards and polices; and scenario planning may all be mentioned. Enterprise architecture framework is generally a tangible manifestation of the mindset of the enterprise architect towards the implementation of the enterprise architecture. To this end, an enterprise architecture framework may be said to be system for the provision of principles and practices that come together to constitute the architecture description for the organization (Paras, 2005). Because of the differences in organizational structures, organizational demand for enterprise architecture and of course differences with preferences of enterprise architects, there are major types of enterprise architecture frameworks that may be used. For example ‘A Reference Architecture for Collaborative Networks’ (ARCON), which is a type of consortia-developed framework, may be used when the architect wants to create a network of enterprises (Weill and Ross, 2004). Reference Model of Open Distribution Process, commonly known as RM-ODP may also be opted by an architect who desires in initiating open distribution systems. There is also solution architecting mechanism (SAM), which is commonly used by architects who want to achieve set of integral modules. But for whichever form or example of enterprise architecture framework that is used, an outstanding identity is that these frameworks are made up of matrices and diagrams that manifest the domains, layers and models that the architect uses in initiating the enterprise architecture. Principles in general are rules and guidelines that inform the parameters based on which the achievement of organizational missions and goals is approached. In this regard, enterprise principles can be said to be the standardization of decision-making options within the organization for the common good of achieving governance stratification. On the other hand, architecture principles could be said to be rules and regulations that gives a level of uniformity in the across the enterprise and decisions on how enterprise architecture should be developed and maintained (Ross, Weill and Robertson, 2006). It is based on these premises that Weill, Subramani and Broadbent (2002) have identified enterprise architecture principle as a coordinated paradigm used for determining the focus of any given enterprise will utilize and deploy its scope of IT resources and properties (McGovern, Stevens and Sharan, 2004). There exist different examples of enterprise architecture, depending on what an organization wants to achieve. In the simplest forms however most organizations make use of examples of enterprise architecture principles including business principles, data principles, and application principles. Business principles cater for such areas of the enterprise architecture such as primacy of principles, information management as everybody’s business, business continuity and service orientation. Data as an asset, data sharing, data accessibility and data trustee also come under data principles, whiles application principles are made up of technology independence and ease-to-use formats of technology. For most modern organizations, technology principles are used as independent principles from application principles and comprise of components such as control of technical diversity and interoperability. The debate on which of current state architecture and future state architecture should come first when dealing with enterprise architecture continues to prevail within the academia and professional practice. Generally, in terms of enterprise architecture, current state architecture refers to the organization and planning of the enterprise based on existing or prevailing standards and matrix available to the organization (Weill and Ross, 2004). For example in the identification of process standardization that should take place for the delivery of goods and services to an organization’s customers, the architecture enterprise may consider the current state of the organization and the level the organization finds its self before making decisions and setting enterprise architecture principles. But in terms of future state architecture, emphasis is placed on where the organization wants to be after a certain period of time. Future state architecture has therefore been said to be more vision focused and pragmatic, as it forecasts the needs of the organization ahead of time and tries to solve the needs today (Schekkerman, 2004). A very typical example of future state architecture is what has been popularized in Germany as ‘Tomorrow’s technology today.’ Commonly, enterprise architects are not faced with the question of differentiating between the two of faced with which of the two to put ahead of the other in enterprise architecture. Whiles reviewers such as Adrian Grigoriu believe that the current state should come ahead of the future state, Philip Allega opines that the future state should come ahead of current state, and the future state should be a vision based on which the current is determined (Allega, 2010). Because enterprise architecture represents not just a part of the organization but the totality of organizations, enterprise architects have always found means to make the concept practical, application, feasible, and easy to use. One of these mechanisms is by breaking the enter system into domains or sub-architectures. An architecture domain may thus be said to be a partial representation of the collective architecture that seeks to shield some aspects of the whole system (Bittler and Keizman, 2005). Architecture domains have been approached by different architects with different types of sub-architectures, depending on what is needed to be achieved. In all, five major sub-architectures may be identified, which are business architecture, data architecture, applications architecture, component architecture, and technical architecture. Whiles business architecture focuses on the overall behavior and composition of the organizational structure, data architecture pays attention to the data entries that the organization uses and how these data are managed. Applications architecture on the other hand focuses on interactivity between individual components of the business including applications, data, portfolio and technologies. Component architecture also embraces the internal structure of the organization, with technical architecture taking charge of the behavior and structure of technology infrastructure (Weill, Subramani and Broadbent, 2002). These sub-architectures can best be learned about by understanding principles behind the multi-complexities of the organization so that the breakdown can be done much easily with the domains. Under each of the domains described earlier, there are specific artifacts or deliverables that are common with them. Generally, artifacts as used in this context refers to the list, tables, diagrams and figures that the enterprise architect designs in the delivering of the collective duty of enterprise architecture (Bittler and Keizman, 2005). The commonest forms of artifacts that may be created from an enterprise architecture program includes requirements and design documents, use cases, class diagrams, and Unified Modeling Language models. A requirements and design document is a written description of the entire design and may be used to serve the purpose of giving descriptive meanings to feature specifications found on architecture diagram (Ross, Weill and Robertson, 2006). Unified modeling language models are also graphic notations given to the static view and dynamic view of the enterprise architecture. The purpose of unified modeling language models are thus to distinguish structural components of the system from its behavioral systems. As the name implies, use cases lists cases or interactions that exist between actors and the system that is being created. It is therefore useful in defining the roles of all actors within the enterprise architecture. Finally, class diagrams break the larger domain down into classes, making it easier to comprehend the process, even from a layman’s view. Governance remains important in enterprise architecture because governance is the platform through which processes and tasks that are expected to be conducted can be conducted properly and according to a given standard (McGovern, Stevens and Sharan, 2004). Governance encompasses several aspects and areas of the enterprise architecture including all five key domains of architecture that have been described earlier. These domains are business architecture, data architecture, applications architecture, component architecture, and technical architecture. But even within each of the domains, governance takes place at various stages of development. Is this means that processes within the enterprise architecture are governed. Such governance system is necessary to ensuring that the processes are orderly and consistent with the scope within which they were initially set. Clearly, an enterprise architecture that does not adhere to strict processes cannot be structured to yield results. Implementation or decision making is also governed. In other words, architecture principles are governed to ensure that decisions that are made as a result of the enterprise architecture are those that can best meet the interest of the organization. The components of governance and their importance has thus been summarized in TOGAF 8.1.1 as being “less about overt control and strict adherence to rules, and more about guidance and effective and equitable usage of resources to ensure sustainability of an organization's strategic objectives” (The Open Group, 2006). Today, it is a very common phenomenon to different between an efficient IT organization and one that is not merely by using the presence or absence of enterprise architecture. This is said as enterprise architecture has been identified to affect the entire organizational structure and organizational climate of any IT organization (Bittler and Keizman, 2005). Ideally therefore, the value of enterprise architecture is in providing governance over the entire IT organization in such a manner that ensures the alignment of business needs with what IT delivers (Lidderdale, 2009). To the enterprise as a whole therefore, enterprise architecture is necessary in the provision of “clear singular vision for IT, and to work to ensure that vision is delivered (Lidderdale, 2009). In the long term, enterprise architecture affects organizations by ensuring that productivity and general delivery takes place in a very rapid and IT cost effective manner with guaranteed success on IT programs and ease with the roles of human resource within the organization. References Allega P. (2010). Future State First, Current State Last. Accessed October 16, 2013 from http://blogs.gartner.com/philip-allega/2010/08/24/future-state-first-current-state-last/ Bittler, R.S. and G. Keizman, (2005). Gartner Enterprise Architecture Process: Evolution 2005. New York: Gartner. Klose, A (2008). Key deliverables of Enterprise Architecture – High level overview Accessed October 16, 2013 from http://blog.prabasiva.com/2008/07/25/key-deliverables-of-enterprise-architecture-high-level-overview/ Lidderdale, P. (2009). The importance of enterprise architecture. Accessed October 16, 2013 from http://www.nationmultimedia.com/2009/03/24/technology/technology_30098694.php McGovern, S.W.A., Stevens, M. E. and Sharan J. L., (2004). A Practical Guide to Enterprise Architecture. 2004, United States of America: Pearson Education. Paras, G., (2005). Creating an Effective Conceptual Architecture. Texas: META Practice. Ross, J.W., P. Weill, and D.C. Robertson, (2006). Enterprise Architecture as Strategy. Boston: Harvard business school publishing. Schekkerman, J., (2004). How to survive in the jungle of Enterprise Architecture Frameworks. Canada: Trafford Publishing The Open Group (2006). Architecture Governance. Accessed October 16, 2013 from http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap26.html Weill, P (2007). MIT Center for Information Systems Research. Sixth e-Business Conference, Barcelona Spain, 27 March 2007. Weill, P. and Ross J.W., (2004). IT Governance. Boston: Harvard business school Publishing Weill, P., Subramani M., and Broadbent M., (2002). Building IT Infrastructure for Strategic Agility. MIT Sloan management review, 1(44): p. 57-65. Read More