EA model as central part of the transfomation into a more flexible and powerful organisation
This report introduces an approach how Enterprise Architecture (EA) design can be deployed in a large financial organisation for strategic transformation. Our EA design embraces all main components of the business organisations, its information systems and the way they work to achieve business objectives. In order to tackle such EA design and its deployment, governance, design and measurement principles are required to keep EA consistent and avoid misunderstandings among stakeholders. Since EA focuses on a holistic view of the organisation, full EA deployment is risky due to cost and organisational impact. Therefore we use an iterative approach within EA deployment that will be considered as an assessment process evaluating the whole IT-landscape of a certain CIO area. There are metrics used which allow the identification of transformation objects and these will be reworked in different structures by using architectural principles and then integrated into EA. Finally the existing EA will be evaluated (together with transformation object) by EA design principles and either the transformation will be rejected or design principles will be adopted. In order to make this model operative it is embedded in an architecture organizational structure which is independent from the organizational structure of the enterprise. 23 To become a business enabler and provide faster time to market within a strong resilient banking environment, is the key focus of EA introduction [WG004]. EA is a discipline which synchronizes the business strategy with the IT strategy. Hence, EA can not be a one-time effort, but is subject to the same change as the enterprise itself. Mergers/Acquisitions, growth strategies or consolidation efforts will heavily impact the way EA is conducted in an enterprise. EA should be a major driver in adapting the IT landscape, which mostly consists of applications and infrastructure, supporting the business processes. Unfortunately, the lifetime of applications in most cases is much longer than the average time between business and IT strategies change. Thus, a flexible approach to EA is needed to drive these changes towards the implementation of the strategies. Our approach is to establish a hierarchy of business-aligned Enterprise Architects and functional and non-functional domains. The functional domains (e.g. Cash Management, Loans Management) cover the IT landscape from a business point of view, whereas the non-functional domains deal with overlapping concerns such as security or integration. On the next level, projects build new business solutions. This approach yields a strong business alignment through business involvement. In addition, the division of the architecture into domains helps to reduce the complexity and assigns responsibilities based on knowledge. It is not an option to deploy EA in one big bang due to the complexity, therefore an iterative approach is required - and this will be described in this report. 2 EA design delivery structure and development approach 2.1 Delivery structure of the target architecture and design principle Architectural design structures as they are suggested by the Zachman Framework [Z1987] or The OPEN ARCHITECTURE GROUP (TOGAF) [TO002] follows a fix structure of multiple layers. As most studies from industrial practise show, adaptations on these models are made to bring case related design into generic design. A full implementation of such a model will often be rejected because of time and costs. Our design uses a simple 4-layered architecture that has been suitable for architectural design in the literature [BFK06], [KAV05], [WG004], [JH007]. Business architecture: Value networks, relationships to customer and supplier, target market segments, offered services, organizational \& strategic business goals and strategic projects Process architecture: Business processes, organizational units, responsibilities, performance indicators and information flows 24 Integration architecture: Enterprise services, application clusters, integration systems and data flows Software architecture: Fundamental software organization artefacts, software services and data structure Practical experiences shows, architectures structured in 4 layers spoil detail and are too granular or generic [MP006],[BSV07]. This causes problems in communication and planning due to various audiences involved. Therefore to avoid misunderstanding between the different viewpoints, architectural layers will be considered with different levels of abstraction. Enterprise level: The enterprise level is the highest abstraction level where all strategic decisions regarding business, operations and IT will be described for a particular closed section of the enterprise. Instead of seeing the whole entity as an enterprise we believe that major business lines as e.g. Private and Corporate Business, Wealth Management or Investment Banking are the appropriate level of abstraction. Therefore the number of enterprise areas should be limited to 3 to 5 in maximum. Domain level: On domain level the strategic goals from the enterprise will be detailed and deployed on domain specific operating models, processes, applications and/ or infrastructure. On this level all guidelines and principles will be defined. Therefore between enterprise and domain level there is a 1:n relationship to achieve a higher granularity in architecture design. For example, the business line Private and Corporate Business will consist of domains as Financing, Investments, Payments, and Current Accounts etc. At minimum 4 domains up to a maximum of 8 domains should belong to one enterprise area. Solution level: The scope of the solution level embraces all applications and their related technical systems. Projects will be performed and delivered out of this level. At this level the detailed technical and business design, software artefacts behave as user interfaces, storage components, computation functions, connectivity components, security components or process components are developed, maintained, tested etc Our architecture design seems feasible for enterprise architecture design. We are able to identify how our architecture may/will be affected by changes or new requirements from either business or technology. However, we need the alignment of the different model dimensions with respect to specific techniques or methods that we have to keep unique in our architectural design; our model may have some drawbacks because of its strict hierarchical structure (i.e. Enterprise services on each layer will be implemented differently). 25 Therefore our architectural design structure will be extended by an additional dimension, so called interdisciplinary dimension. Through this dimension we provide design principles which have an impact on all different architecture levels according to specific scopes. This dimension is required to cover technological aspects; therefore we have defined following scopes: omain olution io Enterprise Enterpris Enterpr Enterp Domain oma om Solut Se In Se Wo fr Business Busi Archi Ar te chi cure Wo cture re cur ast SO rk it ru it Busine Busi ss Proc Pr ess oc Archi Arch etcu ite Archi re cture re ctur A fl ow y ctu ow (B re (B Integra Integ tion ti Archit Ar ecur chit e ectur ecur e e ectur PM ) Sol So ut ft Sol ion wa io wa Ar re chi Ar te ch chi cur itect e ur cur e e ur Figure 1: Enterprise Architecture Delivery Structure SOA: All aspects of Service-Oriented Architecture from service discovery to deployment including methodology, training, coaching, governance and technology. Workflow: Methodology/framework (including governance) and platform definitions to achieve consolidated automation and monitoring of document-centric workflows to become the workflow competency partner to business. Security: Implementation of application security in a cost-efficient, consistent and interoperable manner meeting requirements out of IS Policy Infrastructure: Provides a framework on how to architect applications and services to make best use of infrastructure. This covers infrastructure on various tiers such as Operating System, Persistence and Application Services. The complete delivery structure of our enterprise architectural design model finally considers architecture artefacts in three dimensions: abstraction level (3), architectural layers (4) and interdisciplinary layers (3-n) by following this structure, our EA design implements various relationships between architectural objects e.g. processes or application such that multidimensional behaviour analysis can be performed. Functional or process relationships towards applied technology or applications can be obtained and reasoned with the help of such analysis. 26 Architecture thinking is now well established in many organisations. However, efforts estimates and costs of full EA design are often underestimated and consequently prevent firms to succeed in their architectural objectives [RSV07], [KAV05], and [ABB07]. It is important to achieve objectives that were put for the architectural program in the beginning despite the constraints of budget etc. Many firms try to run independent projects with different scope and topics in order keep efforts feasible. However, due to differences in scope and level some overheads are necessary to align different projects. Although these projects use a predefined structure for the delivered architectural design, it may not be possible to get comparable results, which are interpreted the right way and easily integrated into the general EA model without additional effort. In the literature [RSV07] some investigations are made on how to justify maturity and alignment capability of a given architectural design. Based on such assessment it may become possible to integrate architectural designs at different levels into a single enterprise architecture model at feasible costs. Contrary to previous approaches, in our approach EA design will be deployed in socalled transformation objects with the need to transform the architectural structure in order to improve business enablement or IT quality. Such transformation objects may be identified on different architecture layers or abstraction levels by using an assessment model. The assessment model aims to evaluate the strategic potential of the transformation objects for both business and IT before spending any effort on EA design. Thus architecture design processes for different transformation objects will always be aligned firstly with each other and secondly with strategic and architectural principles striving for the architecture program. As assessment is the central part of our approach, the full process contains some further steps needed to prepare the assessment and finally implementing the transformation objects as well as keeping them in accordance with EA principles. The entire EA development process will be implemented by a V- model as shown in the figure 2: Converge ver d Entepris pr e is Architecture Enterprise Enterp Ente ri rp se ri Strategy Updated and Converged EA Principles Guidance Domain Archit Arch ec it ture Domain Domai Dom n Identification of Transformation Implemented on Objects Transfor Tr mation ts (Assessment) Objects ) ct Transformation Obje Ob cts ct Figure 2: V-Model of Enterprise Architecture Development 27 The assessment uses multi-dimensional evaluation approach, based on this approach the IT landscape will be measured according to their Business contribution, Technical Quality and Costs. Each of the measurement dimensions (e.g. Business contribution) have a certain metrics applied to identify opportunities, bundle them into transformation objects for improvements, quantify their rank and finally define the high level master plan for architectural integration. Assessment of market packages or components-offthe-shelf sometimes is feasible too, as very often adoption and integration into the existing environment needs architecture as well. An assessment can be viewed as snapshot at a certain time. Repetition of the assessment with the same candidate at a later stage is foreseen in this model to prove the impact of architectural changes. It has to be considered that due to changes in markets, technical or organisational realignments etc., not only change transformation objects but will determine the future results. Major advantage of this approach is the involvement of the business units in EA design and the alignment of the business strategies with the IT strategy. 3 Organizational structure making EA work With EA design we identify the areas where we need to transform the architecture of our solutions and better manage the governance of our portfolio. Therefore to achieve this and to better support businesses in their growth targets introduction of EA organisation is a major step towards transformation into a more flexible and service oriented organization. One of the core pillars of this structure will be dedicated Enterprise Architects for each business line. Enterprise architects will work closely with business partners to set the strategic direction of the overall architectural business landscape on the basis of the inputs from the underlying domain. The basic architectural work will be done within domains. Therefore for each domain a domain architect is in charge managing the work of several solution architects. The entire organizational structure of EA with all responsibilities and deliverables is defined in the following table: Level Task Deliverables Enterprise Business Business Vision/Strategy consisting of goals and objectives for Architect Strategy Client and portfolio of investments, roadmap of initiatives for the next 3-5 years, Competitive analysis reports, Business capability roadmaps and initiatives for next 3-5 years IT Strategy IT strategy consisting of goals and objectives for the IT organization over the next 3 to 5 years, given current organization performance and business support needs, technology initiatives proposal (EA input to business strategy), updated IT strategy/vision 28 Level Task Deliverables Governance, Architecture governance model, rules of engagement, roles and Portfolio responsibilities, escalation process, business portfolio model, Definition, portfolio definitions (scope of portfolio in functional or business Organization \& process terms), assets assigned to each portfolio and classified Management (e.g. core, strategic, mission critical, legacy), portfolio strategy, roadmap of programs \& projects. Architecture Architecture marketing and education materials, EA Metrics and communications plan, balanced scorecard framework, Performance architecture measurement system, balanced scorecard report, Management performance action plan Domain Domain IT Strategy consisting of goals and objectives for technology Architect Architecture over the next 3 to 5 years given technology and industry trends, Planning Current state architecture, relevant business \& technology imperatives, guiding principles develop/refresh, gap analysis, future state architecture vision, implementation roadmaps Principles and Guiding principles for IT, EA, design, deployment, policies, data, Requirements security, etc. Domain Process for reviewing solution architectures for compliance with Governance standards, roadmaps and goals for reusability; includes approval and Demand criteria, list of required/optional artifacts at each phase/gate Management Business Business value chain model, business capabilities model, Architecture business process maps, business information model Development Vendor List of strategic IT vendors, Vendor evaluation criteria and Relationship metrics, List of vendor relationship managers; Manage Non- Management strategic vendors Solution Solution Solution requirements, solutions architecture plan with potential Architect Architecture projects, solution architecture plan considering portfolio Design architecture roadmap, technical architecture roadmaps and standards, business case or value case, solution architecture design document Architecture Technical reference model, engineered patterns (i.e. web-user- Requirements interface design, single sign on, rules engine topology, static web and Design content delivery, web personalization, etc) document management patterns, design patters, naming conventions, code frameworks, etc., populated patterns from actual projects/solutions 29 This organizational structure will be embedded in a governance framework to guide the work and ensure the quality of deliverables of all involved parties. The following characteristics are positioned here to highlight both the value and necessity for governance: Discipline: All involved parties will have a commitment to adhere to procedures, processes and authority structures established by the organization Transparency: All actions implemented and their decision support will be available for inspection by authorized organization and provider parties Independence: All processes, decision-making, and mechanisms used will be established to minimize or avoid potential conflicts of interest Accountability: Identify groups within the organization, e.g. Governance Boards, who take actions or make decisions, are authorized and accountable for their actions Responsibility: Each contracted party is required to act responsibly to the organization and its stakeholders 4 EA's evolution over time declares the roadmap for IT convergence The five architecture views described in the previous chapter are usually all affected during the change of a transformation object. This way, the change of the transformation object contributes to IT Convergence on multiple levels.
Full Text: PDF