Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                             Technology ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise Architecture Application Domain Roadmap                                                                        ...
Enterprise architecture4848
Enterprise architecture4848
Enterprise architecture4848
Enterprise architecture4848
Enterprise architecture4848
Enterprise architecture4848
Upcoming SlideShare
Loading in …5
×

Enterprise architecture4848

216 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
216
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Enterprise architecture4848

  1. 1. Enterprise Architecture Application Domain Roadmap Technology Roadmaps Enterprise Architecture Application Domain Roadmap Technology RoadmapsDOCUMENT CONTROLDocument DetailsDocument Owner Tony BrightDocument Author Nick MorgallaCurrent Version 1.1 thIssue Date 25 April 2008Programme Reference Enterprise ArchitectureProject Reference Enterprise Architecture Domain TemplateRevision HistoryDATE VERSION CHANGE DETAILS21st April 2008 1.0 Initial version th25 April 2008 1.1 Incorporate initial feedbackDistributionDATE VERSION DISTRIBUTION st21 April 2008 1.0 Tony Bright, Kapila Munaweera, Phil Burnham and Terry Pyle th25 April 2008 1.1 Architecture Program Board
  2. 2. Enterprise Architecture Application Domain Roadmap Technology RoadmapsTABLE OF CONTENTSEnterprise Architecture Application Domain Roadmap................................................11.0 Introduction .............................................................................................................5 1.1 Objectives....................................................................................................52.0 Executive Summary ................................................................................................6 2.1 Developing the Enterprise-wide Application Strategy .................................6 2.1.1 Complete FABS Rollout...................................................................7 2.1.2 Implement Global Application Standards ........................................7 2.1.3 Pilot Common Application Services.................................................7 2.1.4 Develop Integration Framework ......................................................8 2.2 Potential for Outsourcing.............................................................................83.0 Application Domain Architecture Description ..........................................................8 3.1 British Council’s Enterprise Architecture Approach.....................................9 3.1 Position of the Application Domain within the overall Enterprise Architecture 10 3.2 Capability Summary ..................................................................................10 3.2.1 Customer Facing Services ............................................................11 3.2.2 Integration and Common Application Services..............................13 Internal Services........................................................................................144.0 Direction of Travel .................................................................................................15 4.1 Business changes impacting the Application Domain...............................15 4.1.1 Responding Effectively to the Business ........................................16 4.1.2 Transforming On-line Business .....................................................16 4.1.3 Leveraging Our Information Assets ...............................................16 4.1.4 Increasing Business and IT Efficiency...........................................17 4.2 Technology opportunities ..........................................................................17 4.2.1 Leveraging SAP capabilities..........................................................17 4.2.2 Leveraging Microsoft capabilities ..................................................17 4.2.3 Integration Framework...................................................................18 4.2.4 Software as a Service and Service Oriented Architectures...........19 4.2.5 Web 2.0 (and Web 3.0) .................................................................19 4.3 Exploring the Options ................................................................................20 4.3.1 Mapping Business Change to the Application Domain..................20 4.3.2 Attributes Supporting the Key Business Requirements .................20 Mapping Technology Opportunities to the Application Domain.................21 4.4 Overview of Change..................................................................................23 4.4.1 Maximise SAP Benefit ...................................................................23 4.4.2 Simplify and Standardise Application Architecture ........................23 4.4.3 Create Common Application Services...........................................23 4.5 Summary of Benefits .................................................................................255.0 Detailed Description ..............................................................................................26 5.1 Business Capability / High-level Process Model .......................................26 5.2 Logical Domain Models .............................................................................28 5.2.1 Mapping Products to Application Services ....................................29 5.2.2 Integration Framework Model........................................................30 Page 2 of 38 Published: 01/04/2009
  3. 3. Enterprise Architecture Application Domain Roadmap Technology Roadmaps 5.2.3 Service governance Model ............................................................316.0 Making it Happen ..................................................................................................34 6.1 Technology Choices..................................................................................34 6.1.1 Technology decisions to be made .................................................34 6.2 Key Organisation Processes .....................................................................34 6.3 Resources and Skills.................................................................................35 6.4 Provision Assumptions ..............................................................................35 6.5 Milestones and Deadlines .........................................................................35 6.6 Domain Strategic Roadmap ......................................................................35 6.6.1 Step 1 - Complete FABS Rollout ...................................................36 6.6.2 Step 2 - Implement Application Simplification / Standardisation ...36 6.6.3 Step 3 - Pilot Common Services....................................................36 6.6.4 Step 4 - Implement Lightweight Application Integration Framework36 6.7 Domain Technical Roadmap .....................................................................367.0 Appendix 1 – Principles Guiding the Application Domain .....................................38 7.1 Business Principles ...................................................................................38 7.2 Functional Principles .................................................................................38 7.3 Technical Principles ..................................................................................38 7.4 Implementation Principles .........................................................................38 7.5 Governance Principles ..............................................................................388.0 Appendix 2 – Application Domain Standards........................................................38TABLE OF FIGURESFigure 1 - British Council Enterprise Architecture Approach...............................................9Figure 2 - British Council Enterprise Architecture Domains..............................................10Figure 3 - Application Domain Service Model...................................................................11Figure 4 - Customer Facing Service Model ......................................................................11Figure 5 - Integration & Common Application Services Model .........................................13Figure 6 - Internal Services Model ....................................................................................14Figure 7 - Point-to-Point Integration..................................................................................18Figure 8 - Hub Integration .................................................................................................18Figure 9 - Mapping Business Change to Domain Model ..................................................20Figure 10 - Mapping Technology Opportunities to Domain Model....................................21Figure 11 - Enterprise Architecture Benefits Matrix – Application Domain .......................25Figure 12 - Logical Application Domain Model .................................................................29Figure 13 - Integration Framework Model.........................................................................30Figure 14 - Simple Service Governance Model ................................................................31 Page 3 of 38 Published: 01/04/2009
  4. 4. Enterprise Architecture Application Domain Roadmap Technology RoadmapsFigure 15 - Example Approval Process ............................................................................33Figure 16 - Application Domain Strategic Roadmap.........................................................35Figure 17 - Application Domain Product Roadmap...........................................................37TABLE OF TABLESTable 1 - Application Domain Strategic Approaches ..........................................................6Table 2 - High-level Business Capability and Process Model...........................................27Table 3 - Mapping of Products to Application Services ....................................................29 Page 4 of 38 Published: 01/04/2009
  5. 5. Enterprise Architecture Application Domain Roadmap Technology Roadmaps1.0 IntroductionThis document describes the target architecture roadmap for the Application Domain.1.1 ObjectivesThe objectives of this document are: • To provide a summary of the roadmap for the Application Domain • To communicate an understanding of the Application Domain target architecture to stakeholders at an appropriate level of detail • To position the Application Domain within the overall British Council enterprise architecture and describe the capabilities covered by this domain • To describe how the business direction and technology opportunities have shaped the target domain architecture • To explore the options available to British Council for this domain • To identify the major deadlines and milestones for the delivery of the capabilities provided by this domain • To identify at a high level the resources and skills required to implement the capabilities • To describe the Application Domain roadmap Page 5 of 38 Published: 01/04/2009
  6. 6. Enterprise Architecture Application Domain Roadmap Technology Roadmaps2.0 Executive SummaryThe British Council’s enterprise architecture is currently organised into seven domains. These are data,applications, collaboration, platform, networks, system management and security. This document focuses on theapplication domain.Currently application architectures are decided by the different business departments and are often times passedto GIS to support and sustain. There is a potential for considerable benefit for the British Council if the enterprise-wide application architecture approach described in this document is adopted.However, this represents a considerable step up in terms of enterprise architecture maturity and can only happenwith the support of senior management. In the medium term therefore, it is recommended that the Council focuson one or two specific areas of the business, for example English & Exams and Marketing & Customer Services,though this will still need the specific buy-in and sponsorship of the senior managers within those areas.2.1 Developing the Enterprise-wide Application StrategyBased on current understanding, a strategy based on adopting the following approaches is suggested:Priority Initiative When Key BenefitsHigh Complete the FABS rollout By end 2010 • Return on SAP investment • Increase IT and business efficiency Implement financials MI within • Minimise operational risk SAPHigh Simplify and standardise the Agree architecture • Reduce procurement costs application architecture, specific By end 2009 • Improve customer experience areas of focus: • Improve use of corporate data assets Implement as • Reduced support costs • Web Content Management 1 driven by business • Reduced operational risk • Relationship Management casesHigh Pilot common application Pilot By end 2008 • Maximise use of corporate data assets services in 1 or 2 business • Improve customer experience areas (E&E, MCS), candidates • Reduced operational risk include: • Identity Management • Global SearchMedium Develop integration framework By end 2011 • Reduced procurement costs over time and implement common • Reduced support costs application services • Maximise use of corporate data assets • Improve customer experience • Reduced operational riskTable 1 - Application Domain Strategic Approaches1 Note that general enterprise content management (ECM) is within the Collaboration Domain, though WebContent Management should be considered a subset in architectural terms Page 6 of 38 Published: 01/04/2009
  7. 7. Enterprise Architecture Application Domain Roadmap Technology Roadmaps2.1.1 Complete FABS RolloutThe British Council has made a considerable investment in SAP in the context of the FABS program. Completionof financials rollout is expected imminently and completion of Campus rollout by the end of 2010. During thattime, it is recommended that the SAP architecture is kept relatively stable while the business adopts FABS inorder to minimise operational risk. It is therefore not recommended that the scope of SAP be allowed to creep asthis could threaten the FABS/SAP programme, FABS will have a considerable impact on the business and theyneed time to complete their change management processes before absorbing additional change.2.1.2 Implement Global Application StandardsThere is evidence of application architecture proliferation across the organisation. Two areas where this mighthappen are content management and relationship management. In the case of content management, E&E areexploring a different solution from MCS. In other cases, such as with relationship management, numerous localgeographic solutions have been implemented.This proliferation of solutions is compounded by the tangential Collaboration Domain, where many of theunderlying horizontal tools are identical or similar to those required in the Application Domain.Clearly, this is suboptimal for many reasons adding cost, risk and making it much more difficult to share andbenefit from corporate information. Therefore, a priority is to establish strong governance, especially in this criticalarea, ensuring that the key stakeholders from the business are involved in the process.In some cases, it may well be appropriate to have more than one system provided appropriate integrationmechanisms exist. However, such decisions should be made in a global context, not driven by isolated businesscases.It is imperative that the enterprise architecture team within GIS is given the authority to govern the selection ofsolutions and products. This will require the support of senior management across the organisation.It may take time to enable this globally, in which case it may be appropriate to begin by engaging with one or twobusiness areas. Given the pressing need to establish standards for web content management this indicatesworking with E&E and MCS initially.2.1.3 Pilot Common Application ServicesTwo major objectives of the business are to transform British Council’s on-line presence and maximise benefitfrom corporate data assets. Initial analysis suggests that developing a common mechanism to capture accessand report customer information will benefit both objectives.Currently very little customer information is captured other than for transaction contacts. In some cases it isimpossible to identify from which country a contact was made (IP addresses are not accurate enough).Providing a common identify service will enable the capture of customer information at various levels appropriateto the type of contact. Such an approach can also enable the integration of transaction information within SAPwith the unstructured data that supports much of the on-line user interface with minimal impact on SAP (see 2.1.1above).It is recommended that the British Council initially focus on one area of the business where there is clear businessbenefit, for example E&E. However, it is also important to develop an overall understanding of requirements fromacross the businesses to increase the likelihood of the common service meeting the global need. Page 7 of 38 Published: 01/04/2009
  8. 8. Enterprise Architecture Application Domain Roadmap Technology Roadmaps2.1.4 Develop Integration FrameworkCurrently integration of application components is point-to-point. This is appropriate where there are relativelyfew system components and the business environment is static. The increasing need to respond quickly toaccelerating business change indicates that a better approach to integration will be required in the future.Because the needs of the Council are relatively modest, an integration framework can be lightweight anddeveloped over time. The starting point is to establish the overall architectural approach, set some key standardsand implement strong governance to ensure that all emerging solutions are compliant.2.2 Potential for OutsourcingThe recommended approach to outsourcing is as follows: • Identify the services and processes that are unique to the British Council and give the Council its competitive advantage • Ensure that the Council retains ownership of the architecture and potentially development and support for the systems supporting the services and processes unique to the Council (see bullet above) • Identify current bespoke solutions that can be migrated to industry standard systems and develop migration plan • Consider outsourcing the industry standard solutions to a 3rd party, e.g. SAP • Retain in-house ownership of the overall enterprise architectureThe above approaches are described in more detail in the following sections of this document.3.0 Application Domain Architecture DescriptionThe Application Domain consists of all the British Council business applications, excluding those that are a part ofthe collaboration domain or the platform domain.In summary, these applications provide the following services: • Service Access: o On-line access services (e.g. Web Content Management) o Face-to-face access services (.e.g. Teaching Productivity Tools) o Remote access services (e.g. B2B services such as payroll) • ERP Services • Exams & Teaching Centre Services • Relationship Management Services • Function Support Services • Corporate Performance Management Services (e.g. MI, Dashboards) • Integration and Common Application Services (e.g. Identity Management)The following services are not included in the application domain: • Collaboration services (Collaboration domain) • Generic Content Management (Collaboration Domain) • Workflow (Collaboration domain) • Mail and messaging (Platform domain) • MS Office (Platform domain) • Desktop productivity tools (Platform domain) • System and Service Management tools (System Management domain) Page 8 of 38 Published: 01/04/2009
  9. 9. Enterprise Architecture Application Domain Roadmap Technology RoadmapsHowever, it is unwise to ignore the application services that are not directly a part of the Application Domain whenconsidering the overall applications architecture. This is because either now or in the future there may be a needfor integration of components across the complete applications landscape. In addition, re-usable components canexist within each of the domains, so the Applications, Collaboration and Platform domains should be consideredwhen exploring new potential solutions.Therefore, in places this document includes references to those application components that are outside thedefined scope of the domain.3.1 British Council’s Enterprise Architecture ApproachThe Enterprise Architecture is a comprehensive framework used to manage and align an organisations businessprocesses, Information Technology (IT), software, hardware and information requirements with the organisation’soverall business strategy.Figure 1 - British Council Enterprise Architecture ApproachThe document focuses on defining the future state model for the Application Domain.As part of the overall enterprise ‘architecting’ process, a number of guiding principles have been developed.Those principles that specifically affect the Application Domain can be found at the back of this document inSection 7.0 Appendix 1 – Principles Guiding the Application Domain. Page 9 of 38 Published: 01/04/2009
  10. 10. Enterprise Architecture Application Domain Roadmap Technology Roadmaps3.1 Position of the Application Domain within the overall Enterprise Architecture Business On-line Face-to-face Cross-team Focus Outreach Service Experience Working Business Efficiency Service Management Architecture English & Business Arts Exams Education Science Governance Common Services Enterprise Functions Support Services Security Architecture Information Knowledge Information Data Collaboration On-line Access Face-to-face Access Remote Access Architecture Technical Integration & Common Application Services Exams & Teaching Relationship Function Support Corp Perf ERP Centre Services Management Services Services Mgmt Services Systems Manage Platform ment NetworkFigure 2 - British Council Enterprise Architecture DomainsThe Application Domain is one of seven enterprise architecture domains currently identified within the BritishCouncil. The ‘in-scope’ domains are shown within the red box in the picture above.The application domain incorporates the main business applications and excludes application components thatare part of the collaboration or platform domains (see introduction to this section above).The capabilities of the Application Domain are listed in detail below.3.2 Capability SummaryApplication services fall into one of three areas: • Customer Facing Services – services directly accessed by British Council’s customer and partners • Integration and Common Services – the mechanism for integrating services across different systems and providing consistent common services to systems • Internal Services – services which enable the British Council to run its businesses but which are not directly accessible to its customers or partners Page 10 of 38 Published: 01/04/2009
  11. 11. Enterprise Architecture Application Domain Roadmap Technology Roadmaps Customer Facing Services Integration & Common Services Internal ServicesFigure 3 - Application Domain Service Model3.2.1 Customer Facing Services Customer Facing Services On-line Face to Remote Access Face Access (Web site) Access (Contact (Teaching Centre, Centre) Partner)Figure 4 - Customer Facing Service Model3.2.1.1 On-line access servicesWhile a considerable amount of business still takes place face-to-face, there is an emerging trend to increase on-line activity. On-line activity can take a number of different forms. Page 11 of 38 Published: 01/04/2009
  12. 12. Enterprise Architecture Application Domain Roadmap Technology RoadmapsInteraction ServicesInteraction services are services that enable British Council’s customers to interact with each other as well as theCouncil, for example: • Blogs • Wikis • eMail • Chat • Emerging capabilities – still to be definedNote that this is a fast moving area and new requirements and capabilities are expected to emerge on an ongoingbasis.These Interaction Services are a strong example of the tendency for service functionality to cross Domainboundaries; all of the above are candidate services in the Collaboration Domain and furthermore, interactions willoften start as internal interaction (‘Collaboration’) before resulting in client-facing dialogue (‘Applications’), or viceversa.Transactional Services • Registration • Order Capture • On-line Training • On-line Exams (potential future requirement) • Enterprise FeedbackThe recurrent need to ‘know who the customer is’ makes early registration and encouragement of sign-on a highlydesired behaviour; the implementation of cross-platform behaviour (for client-facing, ‘Web’ applications) makesthe proliferation of Web Content Management solutions of particular concern.Web Content Delivery • Media streamingWeb Content Management • Content Authoring • Content Lifecycle Management • Performance Management (May be part of the Systems Management Domain)Content Authoring and Lifecycle Management are activities that take place in the Collaboration Domain andfrequently cross Domain boundaries; the implementation of services that do not have the ability to operateseamlessly across these boundaries will, at best, lead to cost multiplication and user inconvenience.3.2.1.2 Face-to-face access services • Events Management • Learning Productivity Tools3.2.1.3 Remote access services • Order Capture Validation Page 12 of 38 Published: 01/04/2009
  13. 13. Enterprise Architecture Application Domain Roadmap Technology Roadmaps • Customer Support • B2B Partners (e.g. The British Accreditation Council, Cambridge Assessment) • B2B Suppliers (e.g. Logica, Global Crossing, HP)3.2.2 Integration and Common Application Services Integration & Common Application Services Common Integration Service Services Platform Lifecycle ManagementFigure 5 - Integration & Common Application Services Model3.2.2.1 Common Application Services • Identity and Authentication Services • Search Services • Common Content Management Services • Web AnalyticsCurrently a small set of potential common application services has been identified, however more work needs tobe done with the business units to identify which business services need to be common, and which can remainspecific to point business solutions.3.2.2.2 Integration Framework • Security (access control) Services • Service Auditing • 2 Service Orchestration • Service Instrumentation 3 • Service Management o Availability Management o Performance Management2 Combining two or more services together in a sequence to perform a business function3 Incorporating functionality within a service to log and report performance and behaviour in business terms, forexample to measure how often a user enters an invalid data item, or how long it takes to complete on on-linecourse booking Page 13 of 38 Published: 01/04/2009
  14. 14. Enterprise Architecture Application Domain Roadmap Technology RoadmapsA good example of a service which should be made available through the integration framework is commonidentity management. Providing the service through the common framework will make it easier for serviceconsumers to access the service in a simple and consistent manner. It will also provide the control andmonitoring required to deliver the service effectively.In the identity management example, the service would need to be used by multiple channels, including on-linesystems, call centres and possibly even when registering face-to-face contacts. For on-line integration, the on-line system can call a simple web-service to capture the user identity and any security identifiers and provide asimple go/no-go response.This same web-service could also be used by a simple stand-alone, or lightly integrated front-end that could beused in call centres. Such a (front-end) component could easily be developed and supported in-house. Overtime, as the existing contact centre system is migrated to a common platform, a more robust integration would beimplemented, but still using the same common identity service.3.2.2.3 Service Lifecycle Management • Service Definition and Standards • Service Catalogue • Service Publication & Discovery • Service Contract Management • Service Quality Assurance • Service GovernanceInternal Services Internal Services ERP Exams & Relationship Function Corporate Services Teaching Management Support Performance Centre Services Services Management Services ServicesFigure 6 - Internal Services Model Page 14 of 38 Published: 01/04/2009
  15. 15. Enterprise Architecture Application Domain Roadmap Technology Roadmaps3.2.2.4 ERP Services • Purchase Order Accounting • Sales Order Processing • Accounts Receivable • Accounts Payable • Billing Invoicing • Contract Accounting • General Ledger • Financial Reporting • Travel & Expenses • Sourcing Contract Reviews • Product Catalogue • Order Management • Order Fulfilment • Stock Management3.2.2.5 Exams & Teaching Centre Services • Course Registration • Exam Registration • Teaching Centre Management • Student Exchange Management3.2.2.6 Relationship Management Services • Contact Management • Call Centre Management • Strategic Partner Management3.2.2.7 Function Support Services • Asset Management • Human Resources • Payroll • Records Management • Library Management • IT Service Management (may be part of the Systems Management Domain)3.2.2.8 Corporate Performance Management Services • Corporate Performance Monitoring BI • KPI Dashboard4.0 Direction of Travel4.1 Business changes impacting the Application DomainThe key business changes that affect the Application Domain in the near future are: Page 15 of 38 Published: 01/04/2009
  16. 16. Enterprise Architecture Application Domain Roadmap Technology Roadmaps4.1.1 Responding Effectively to the BusinessThe British Council is, like many organisations, experiencing a major shift from doing business face-to-face to on-line working. A feature of this change is that it is moving very quickly and subject to many short-lived fads andfashions.Many of the British Council’s customers will be involved in this change and in order for the British Council to thriveand survive it must be able to compete and lead the field in terms of its on-line presence.The dynamic nature of this environment means that IT has to be even more responsive to demands from thebusiness otherwise the British Council is in danger of losing the race with its competitors.In order to achieve such levels of responsiveness it is imperative that business solutions can be quickly built upfrom existing components or ‘services’ rather than having to acquire complete systems from scratch every timerequirements change.4.1.2 Transforming On-line BusinessOn-line transformation is fundamental to the future growth and success of British Council. As noted above, thereis a significant move from face-to-face to on-line working. However, it is no longer enough just to have a webpresence. If the British Council is to attract and keep customers it must provide a leading-edge on-lineexperience, otherwise it will quickly loose business to its competitors.Emerging technologies such as Web 2.0 and eventually Web 3.0 are beginning to transform how we think aboutand use the Internet and other communication channels.Access to the internet is becoming widespread, even in third world countries 4 . British Council’s target audience israpidly becoming web ‘savvy’ and is attracted by these new technologies.The growth of the high profile Social Networking sites, which take a significant percentage of many web users‘mindshare’, may force organisations to ‘take their content to the user’; rather than to ask ‘how do we competewith (for instance) Facebook?’, it may be better to develop a strategy of being present on these sites.It must be possible to integrate new and emerging technologies into existing solutions with minimal disruption. Itis not enough just to ‘bolt on’ new functionality without integration since this will not provide the best userexperience nor make available the consistent valuable information required by the Council.The business requirements for internal systems tend to be far more stable and much more likely to evolve slowly.A key challenge is to develop an architecture that will successfully mesh these two seemingly conflictingrequirements.4.1.3 Leveraging Our Information AssetsInformation is one of the British Council’s major assets. In the past, it has been challenging to leverage theseinformation assets across the organisation partly because of the way the business is organised, but also becauseof the disparate applications architecture (it could be argued in turn that this is a result of the businessorganisation).The introduction of SAP via the FABS program has enabled considerable progress to be made in this area,especially in terms of financial data. However, there is still much information, especially relating to BritishCouncil’s customer, which is inconsistent, difficult to manage and reconcile.4 Currently in some countries, access to the internet may be via mobile phone. Page 16 of 38 Published: 01/04/2009
  17. 17. Enterprise Architecture Application Domain Roadmap Technology RoadmapsIn some cases, valuable information is simply lost (for example, who is accessing a web site) because nomechanism is available to capture that data. Even where data is captured, it is challenging to reconcile it acrossprocess boundaries and this significantly reduces the value of the information.While part of the solution to this is outside the scope of the application domain (because it sits within the DataDomain), it is the application that will collect process and deliver the information to maximise its use.4.1.4 Increasing Business and IT EfficiencyAnother key business objective is to optimise both business and IT efficiency. This involves balancing ITinvestment against business value, and ensuring that maximum value is obtained from existing IT assets.When applied to the British Council application architecture domain, this means leveraging as much value aspossible from the SAP and Microsoft applications and infrastructure.It also indicates that there is a need to simplify and standardise the application domain. This means that theBritish Council must ensure that as far as possible, solutions are designed for use and re-use across the wholeorganisation.4.2 Technology opportunitiesA number of technology opportunities can have an impact on the application domain. These include:4.2.1 Leveraging SAP capabilitiesThe British Council has made a considerable investment in SAP in terms of both solutions and capability.Wherever possible and where it meets requirements, SAP should be used to provide functionality. This is mostlikely to be in the area of internal services where there is likely to be a close (enough) match between businessrequirements and application functionality. It is also generally easier, though not without its challenges, to changebusiness processes internally to match SAP’s implemented processes.However, SAP is less likely to provide the flexibility that is required, especially for on-line access other than in thearea of transactional access. It may be better to expose SAP functionality thorough a common service interface,allowing the Council to develop user interfaces quickly and effectively.Consideration also needs to be given to the cost and availability of SAP resources when implementing newfunctionality.More investigation of the capabilities of SAP needs to take place before any hard and fast decisions are made inthis area.4.2.2 Leveraging Microsoft capabilitiesAs with SAP, the British Council has made considerable investment in Microsoft Infrastructure again both in termsof solutions and capability. In addition, the British Council’s status as an educational establishment means that itreceives favourable licensing pricing for all Microsoft products.Microsoft provides capabilities for implementing an integration framework based on .NET and BizTalk Servertechnologies (See 4.2.3 below). MOSS should also be included as a potential solution development platform. Page 17 of 38 Published: 01/04/2009
  18. 18. Enterprise Architecture Application Domain Roadmap Technology Roadmaps4.2.3 Integration FrameworkThe requirement to be able to build solutions fromcomponents and to combine functionality andinformation from a number of different systems stronglyindicates the need for integration. System A System ETraditionally integration has happened in an ad-hocpoint-to-point manner. Such an approach rapidlyreaches unmanageable proportions as the number of System Cintegration points increases.An added complication in such an arrangement is thatthere can be a lack of standardisation between point-to-point integration mechanisms. This can make itincreasingly difficult to support and over time this canlead to a critical situation where if becomesexceedingly difficult to integrate any additional System D System Bcomponents. Figure 7 - Point-to-Point Integration A better approach is to implement a common integration framework that acts as a ‘hub’ When a system requires a service, it System A System E communicates with the central framework rather than the service provider directly. The framework knows where to find the service because it keeps track of service providers. In such an arrangement, the total number of integration points equals the total number of Integration Framework systems to be integrated. In addition, because every integration point uses a common standard, the solution is much easier to support. Such an arrangement makes it very easy to change where a service is provided from in the future. For example, identity management may System B System C System D initially be provided in-house but in the future may be provided by a third party. This requires a simple parameter change within the framework. Figure 8 - Hub IntegrationOnce the concept of an integration framework has been accepted, a natural progression is to move common‘technical’ functionality, such as auditing, error handling and service instrumentation into the framework itself sothat it does not have to be implemented repeatedly by each application.An integration framework can provide a pre-defined set of standards, tools and common service components.Applying British Council’s architecture principles there are a number of candidates for the provision of anintegration framework, for example based on SAP using SAP’s Netweaver technologies, or alternatively based onMicrosoft’s technologies such as .NET and MOSS. Page 18 of 38 Published: 01/04/2009
  19. 19. Enterprise Architecture Application Domain Roadmap Technology RoadmapsAn integration framework does not have to be a huge investment, in fact, experience has shown that it is muchbetter to start small and grow outwards. The starting point is to establish a set of standards and a governanceprocess to ensure that all new solutions consider the use of the integration framework and the common servicesthat it can support.An example of a common service might be identity management which can help the British Council to gain amuch better understanding of who they interact with, who is using on-line services and enable tracking customerengagement over time.4.2.4 Software as a Service and Service Oriented ArchitecturesSoftware as a service (SaaS) is a software application delivery model where a software vendor develops a web-native software application and hosts and operates (either independently or through a third-party) the applicationfor use by its customers over the Internet.Customers do not pay for owning the software itself but rather for using it. They use it through an API accessibleover the Web and often written using Web Services or REST. The term SaaS has become the industry preferredterm, generally replacing the earlier terms Application Service Provider (ASP) and On-Demand.Service Oriented Architecture (SOA) is a computer systems architectural style for creating and using businessprocesses, packaged as services, throughout their lifecycle. SOA also defines and provisions the IT infrastructureto allow different applications to exchange data and participate in business processes. These functions areloosely coupled with the operating systems and programming languages underlying the applications.SOA separates functions into distinct units (services), which can be distributed over a network and can becombined and reused to create business applications. These services communicate with each other by passingdata from one service to another, or by coordinating an activity between two or more services.SOA concepts are often seen as built upon and evolving from older concepts of distributed computing andmodular programming.While the British Council’s current requirements do not suggest a wholesale move toward SOA architecture,adopting some of the SOA principles, applying a ‘light touch’ can be beneficial, especially when considering theprovisioning of common application services. In some cases it may be possible and beneficial to provide suchservices, for example identity management, as SaaS, in which case SOA can be seen as an enabler.4.2.5 Web 2.0 (and Web 3.0)Web 2.0 is having a significant impact on how people perceive and use the Internet. Web 2.0 allows users muchgreater control over how content is created and accessed. It also potentially allows users to provide a muchgreater degree of customisation of their personal web experience.A key question for British Council is how can the Web 2.0 capabilities be integrated into the overall architecturewhile maintaining the benefits of Web 2.0 and without adversely affecting the core BC systems.However, Web 2.0 services are provisioned there is a need to define a set of common interfaces which will enablethe British Council to maximise the overall benefits of these technologies. Page 19 of 38 Published: 01/04/2009
  20. 20. Enterprise Architecture Application Domain Roadmap Technology Roadmaps4.3 Exploring the OptionsThe next step is to begin to map the business changes and technology opportunities onto the application domainmodel to understand how they can affect the British Council’s target application architecture.4.3.1 Mapping Business Change to the Application Domain Transforming On-line Customer Facing Services Business Responding Integration & Effectively to Common Leveraging Business Services Information Assets Business and IT Efficiency Internal ServicesFigure 9 - Mapping Business Change to Domain Model4.3.2 Attributes Supporting the Key Business RequirementsConsidering the mapping of business change to the application domain, a number of characteristic emerge whichbegin to describe the architecture desired state.4.3.2.1 Attributes - Responding Effectively to Business • Simplified • Reusable • Modular • Open standards • Easy to integrate • Strong governance4.3.2.2 Attributes - Transforming on-line business • Consistent British Council branding, look and feel • Compelling • Functionality - ability to access services and information • Easy to use Page 20 of 38 Published: 01/04/2009
  21. 21. Enterprise Architecture Application Domain Roadmap Technology Roadmaps4.3.2.3 Attributes - Leveraging Information Assets • Consistent data access mechanisms • Data quality and validation • Data standards • Taxonomy and metadata • Master data management4.3.2.4 Attributes - Business & IT Efficiency • Business process standardisation • Leveraging IT assets • Reuse • Strong governanceMapping Technology Opportunities to the Application Domain Web 2.0 (and Web 3.0) Customer Facing Services Integration Integration & Framework Leveraging Common Microsoft Services Capabilities Leveraging SAP Internal Services CapabilitiesFigure 10 - Mapping Technology Opportunities to Domain Model4.3.2.5 Technology Mapping - Leveraging SAP CapabilitiesWhere SAP is a good fit, which is primary in the financial management and transactional areas it should be usedto meet future requirements. Page 21 of 38 Published: 01/04/2009
  22. 22. Enterprise Architecture Application Domain Roadmap Technology RoadmapsIn general, SAP sits most comfortably in the Internal Services area, however SAP can also be used to providetransactional interfaces which are customer facing. Consideration needs to be given to the ease and speed atwhich such interfaces can be changed, and whether interfaces support the look and feel of British Councils on-line presence.SAP is currently being rolled out in the context of the FABS program. The financials functions rollout will becompleted imminently, and the Campus functionality is due to complete in 2010. While this rollout is taking placeit is important to minimise the impact and any risk to the SAP environment, which means limiting additionalprograms of work that involves SAP.Potentially SAP could also be used to implement relationship management, although more work is needed toexplore the requirements in the context of the overall enterprise architecture.4.3.2.6 Leveraging Microsoft Capabilities / Integration FrameworkAs described in 4.2.2 and 4.2.3 above, Microsoft technologies appear to be a good fit to provide the integrationlayer that connects the customer facing to internal services and provides a consistent set of common services,such as identity management.In particular, many organisations are recognising that MOSS provides not only a framework for Collaboration,internal Content Management and Web Content Management, but also the ability to expose ‘non-native’ contentthrough a common metaphor supported by platform functionality and behaviours (e.g. Discussion, Wikis).4.3.2.7 Web 2.0The new and emerging Web technologies clearly will have most impact on customer facing services.The underlying concept of Web 2.0 is that the Web becomes the ‘platform’ and that user’s gain control over theirpersonal data and user experience.This can be interpreted in a number of ways: • Users contribute to content (e.g. Wiki’s Blogs) • Users can create their own browsing experience (customised web sites) • Much richer end-user functionality (Web applications)Exactly what this means to the British Council is still emerging, but the pragmatic approach is to ensure that Web2.0 and other technologies that will come in the future can be integrated painlessly and effectively into solutions.Assuming the above is valid; this indicates that the British Council needs an architecture that has the followingattributes: • Based on open standards • Integration framework to provide the underlying ‘plumbing’ • Strong governance to ensure that solutions comply with architecture and standardsApplying one of the principles of re-use, Technical Principle 2 - Maximising Microsoft Infrastructure Benefits, theBritish Council should investigate how to leverage capability from MOSS. Although MOSS is primarily used todayto provide internal collaboration functionality, its capabilities go beyond that. More research needs to be done,based on a deeper understanding of the business requirements. Page 22 of 38 Published: 01/04/2009
  23. 23. Enterprise Architecture Application Domain Roadmap Technology Roadmaps4.4 Overview of Change4.4.1 Maximise SAP BenefitThe British Council has made a significant investment in SAP. The initial FABS program is in the process ofbeing rolled out to the businesses and this needs to be completed before any major new SAP programs areimplemented. Completion of the FABS rollout is expected by 2010.4.4.2 Simplify and Standardise Application ArchitectureCurrently individual businesses are responsible for choosing applications, and there is limited global governanceto alter this behaviour, there is an ongoing risk of several systems being implemented which duplicatefunctionality. This may happen for example in the case of relationship management or content management.Different business units or geographies are independently assessing software requirements and piloting solutions.The British Council could gain significant benefit by ensuring that all the relevant businesses work together withGIS enterprise architects to ensure that there is consistency and collaboration between systems.Some potential advantages of a standardised approach: • Reduced acquisition costs – greater buying power if focussed on smaller number of suppliers • Reduced development costs – develop the solution only once • Reduced support costs – need to support less systems • Consistent user experience • Makes it easier to share information within and across departmentsThe areas that require the most urgent attention are: • Web Content Management • Relationship ManagementOver time, strong enterprise architecture governance should be implemented, but this will require the buy-in fromthe businesses. In the short term, GIS should engage more closely with the business areas that are exploringemerging requirements, such as content management to determine if it is possible to move toward a standardisedsolution.4.4.3 Create Common Application ServicesEven assuming that the application domain is simplified and standardised, there are still common functions andinformation that should be shared across applications.Many on-line components will need to use a core set of functions, for example ‘search’, and ideally these shouldbe provided once only in a consistent manner across the organisation.In order to support the rapidly changing on-line world, on-line components will need to be created and integratedwith existing systems quickly and efficiently. This is likely to be an increasing important requirement over time.While it is possible to provide common application services in a point-to-point integration architecture,implementing ‘light touch’ integration framework can provide many significant benefits: • An open, standards based framework into which components can be easily plugged and unplugged • Loose coupling of components, ensure that components do not become interdependent – this includes both on-line and back-end components • A core set of standard re-usable functions, for example identity management, search, auditing, provided as services with well defined service level agreements • A clearly defined integration mechanism with existing applications Page 23 of 38 Published: 01/04/2009
  24. 24. Enterprise Architecture Application Domain Roadmap Technology Roadmaps • A simple published repository of re-usable components and services • A lightweight mechanism to manage and govern components, services and solutionsThe benefits of adopting this approach are: • Consistent end user experience when engaging across the organisation • Consistent customer information across the organisation • Maximise re-use, optimum use of resources • Leverage maximum capability from existing investments, including the Microsoft and SAP platform • Flexibility and agility, easy to make changes with minimum impact on existing servicesInitial exploration indicates that the provision of a common identity would be a good place to start. An approach tothis might be as follows: 1. Identify where identity services are currently used with the global business 2. Do deeper analysis of the data and processes involved with identity within one or two specific business areas, e.g. E&E 3. Create metadata model for customer, keep it simple initially 4. Validate model across business units, run simple scenarios to test validity 5 5. Implement architecture governance to apply the model 6. Develop simple common identity service to support business specific requirements, working initially within one area of the business 7. Validate service against business process 8. Implement governance to implement common identity serviceThe development of such services should be underpinned by a good understanding of the business informationand processes that define the requirement. An important activity is to identify the common areas of data, forexample customer, and process for example user authentication and understand where these fit into the overallbusiness model.This will require an initial high level understanding across the business, together with a more detailed drill-downfor one or two specific business areas, followed by validation across the rest of the organisation.5 All new solutions must comply with model, develop plan to retrofit where there is a proven business case Page 24 of 38 Published: 01/04/2009
  25. 25. Enterprise Architecture Application Domain Roadmap Technology Roadmaps4.5 Summary of Benefits Applications Common Application Services Application Standardisation Application Integration Complete SAP Rollout 21 20 20 15Prioritisation RatingDifficulty (1 = easy, 5 = difficult) 2 3 3 3Cost (1 = low, 5 = high) 4 3 3 3Dependency Factor (1 = has dependents, 5 = no dependents) 1 1 2 3 Importance (1  = low, 5 = Benefit high)Increase business efficiency 5 4 5 5 3Reduce operational risk 3 4 5 3 2Faster time‐to‐market 3 5 4 5 5Flexible business relocation 3 5 4 3 3Flexible delivery channel support 2 3 4 5 5Flexible working (e.g. 3rd parties) 2 1 3 4 5Better access to information 4 3 4 5 5Improve service quality 3 3 4 4 3Improve scalability 3 4 4 4 3Reduce IT costs 5 5 2 3 5Strengthen compliance & security 4 3 3 5 2Reduce training needs 1 4 1 1 1 144 141 156 137Value (Higher = more value)Figure 11 - Enterprise Architecture Benefits Matrix – Application DomainFigure 11 above illustrates the relative benefits attributed to the initiatives described in this document. It can beseen that based on the above assessment, application standardisation has the highest priority, followed closelyby completion of SAP rollout and common application services.Implementing application integration is less compelling; however it is likely to become more important over timeand should therefore still be given consideration. Page 25 of 38 Published: 01/04/2009
  26. 26. Enterprise Architecture Application Domain Roadmap Technology Roadmaps5.0 Detailed Description5.1 Business Capability / High-level Process ModelThe starting point for developing the application architecture is the business process model. While currently thebusiness architecture is outside the defined scope of enterprise architecture within the British council, it isincluded in conceptual form because of its critical importance.This model needs to be validated and developed in conjunction with the business. Sector or Service Service Category Consumer Service Primary Activity High Level Processes Arts Customers Arts Art Promotion Registration (Event) Events Management Creative Economy Education Customers Learning Teaching English Registration (Course) Budget Planning Course Management Teaching Scholarships Scholarship Management Counselling Educational Counselling Teaching Teacher Training Accreditation Teaching exchange Exchange Management (Teaching) Exams Examinations Registration (Exam) Exam Management Examining International Experience Youth Exchange Exchange Management (Youth) Training Exchange Exchange Management (Training) Promotion Education Promotion Science Customers Science Science & Technology Accessing UK Science Library Library Management Governance Customers Governance (Enterprise Function - ESS) Development Development Project Management (Enterprise Function - ESS) English Customers (Enterprise Function - E&E) Common Customers Finance Billing Billing / Invoicing Services Payments Payment Processing Page 26 of 38 Published: 01/04/2009
  27. 27. Enterprise Architecture Application Domain Roadmap Technology Roadmaps Product Product Development Product Design Product Lifecycle Management Product Service Catalogue Marketing (Enterprise Function - Marketing) Enterprise Customers, Sector Teams English and Exams (E&E) Supporting Tools Functions Partners (Supporting fulfilment) (UK based) and BC Education, Science & Society (ESS) Arts Finding artists and art professionals Partnership Teams Commercial & Business Partnerships Franchising UK Directorate (UKD) Service Teams Marketing & Customer Services Marketing (MCS) Relationship Management Customer Service Contracts and Projects Procurement Winning projects Project Management Governance (Society) Support BC Global IS Procurement Services Service Management Global Estates Facilities Management Corporate Affairs Corporate Planning & Performance Legal Accounting HR Programme Support Office (PSO)Table 2 - High-level Business Capability and Process ModelConsiderable work needs to be done in collaboration with the business to refine this model; however, it currentlyserves as a placeholder. Page 27 of 38 Published: 01/04/2009
  28. 28. Enterprise Architecture Application Domain Roadmap Technology Roadmaps5.2 Logical Domain Models Note, these capabilities are not . contained within the Application Domain, but are included to show the overall applications landscape, and identify any dependencies and integration touch-points Part of the Data domain, included . here for completeness Page 28 of 38 Published: 01/04/2009
  29. 29. Enterprise Architecture Application Domain Roadmap Technology RoadmapsFigure 12 - Logical Application Domain ModelThe logical application domain model represented in Figure 12 shows the domain organised into the majorfunctional areas. To avoid over complicating the diagram, Integration and common application services areshown as internal services, though in reality they can be considered as sitting between customer facing andinternal.5.2.1 Mapping Products to Application ServicesCategory Group Service ProductCustomer Facing Services On-line Access Interaction Services Web 2.0 components Transactional Services SAP plus other GUI Content Delivery Web Content To be identified Management Face-to-face access Events Management To be identified Learning productivity tools Various Remote Access Customer Support front To be identified end B2B Access Integration FrameworkIntegration & Common Integration Framework See 5.2.2 below Initial lightweightServices implementation may not require specific product, but could be ,NET or MOSS Common Services Identity Management To be identified, could be DAP, directory based service Search To be indentified Metadata management MOSSInternal Services ERP / Financials Package SAP Exams & Teaching Campus SAP Centre Services Relationship To be identified, potentially Management Services SAP or Microsoft or other product Function Support Various Internal bespoke systems Corporate Performance BI SAP Management Dashboard To be identifiedTable 3 - Mapping of Products to Application Services Page 29 of 38 Published: 01/04/2009
  30. 30. Enterprise Architecture Application Domain Roadmap Technology Roadmaps5.2.2 Integration Framework Model Face 2 Face On-line System 1 On-line System 2 Remote System 3rd Party Integration System Integration Framework Run-time Capabilities Design-time Capabilities Service Publication & Security Routing Orchestration Repository / Discovery Catalogue Service Error & Event Performance & Service Audit Handling Availability Governance Management Common Application Services Bespoke Identity Search SAP CRM Management SystemsFigure 13 - Integration Framework ModelFigure 13 above illustrates the typical capabilities of a mature integration framework. This model represents apotential desirable end-state; however, the initial requirements for the British Council are modest and it is notnecessary to implement all of these capabilities in one go.It is however important to ensure that there is an overall architecture vision which will lead to the target model if sodesired.The key requirements are: • Clearly defined interface standards • Security • Service catalogue, to drive re-use and enable governance • Basic service governance to ensure compliance with the model and standards Page 30 of 38 Published: 01/04/2009
  31. 31. Enterprise Architecture Application Domain Roadmap Technology RoadmapsInitial common application services might include: • Identity management • Search • Content management – metadata5.2.3 Service governance ModelExperience has shown that it is essential to establish effective governance from the very beginning whenimplementing common application services. Failure to do this will typically lead to poor implementation ofstandards leading to inconsistency across the organisation and reduced benefit of re-use existing components.Figure 14 - Simple Service Governance ModelFigure 14 illustrates a model for service governance that could easily be implemented in part or whole by theCouncil.The British Council does not need to implement heavyweight service governance, and at this stage, it is probablynot appropriate to implement sophisticated tools to support this. The use of SharePoint as a repository for servicegovernance artefacts is appropriate.If over time, a significant volume of shared services are developed, it may be worth considering a servicegovernance toolset.5.2.3.1 Business ServicesEnsure that the service is described clearly in business terms. This will enable prospective users of the service todetermine if it is fit for their purposes.Define the levels of service, for example hours of operation, performance that will be provided. Page 31 of 38 Published: 01/04/2009
  32. 32. Enterprise Architecture Application Domain Roadmap Technology Roadmaps5.2.3.2 PoliciesDetermine which rules and policies a service must be compliant with before it can be released into the productionenvironment.Policies may in turn contain specific assertions that can be thought of as specific tests to ensure a serviceconforms to architectural and business requirements.5.2.3.3 Approval ProcessHow will the service be specified, designed, built, tested and finally released into production? Who is responsiblefor signing off each stage of the service lifecycle?Figure 15 below represents an example of how a service approval process might look. The important elementsare the gates that sit between each stage, and the release mechanisms that ensure that services are not releasedinto the production environment unless they are compliant with standards and other requirements. Page 32 of 38 Published: 01/04/2009

×