It’s not my intention to make this a text book session and bore you to death. But we should have a single way of understanding EA before we move on. This definition comes from The Open Group Architecture Framework which is the product a very large number of EA practioners and organisations – including myself. Think of structure as just the different pieces that exist to do something. Imagine you get a two line email from a significant business sponsor who you never want as an enemy. You know it’s serious as the email is all in UPPER case. The message reads, APPLICATION X IS NOT WORKING, RESOLVE IMMEDIATELY! What do you do in this scenario? Head for the hills til it blows over? The better thing to do would probably be to troubleshoot the problem. So firstly you’d want to know is it a functionality issue. Is the system failing to do something it should. Is their access incorrect for the task? Have we lost information? Has the application crashed or non-responding? Is the technology down? And after all these questions you find out the actual issue is power is out at their location. It’s only through differentiating the different parts that the correct problem can be ascertained. Similarly if we understand the different components that are needed, and how they should be structured we can more effectively put them together. I’m not sure why but a school scenario popped into my head to explain this further. There’s a certain structure within a class room of students. Generally the people who want to misbehave sit toward the back. And kids who want to focus on learning – or just avoid the kids at the back – site at the front. Bad students can then be brought to the front for more visibility. And from there they can also be removed entirely if there’s no hope for them. The teacher will also come to know the inter-relationships that exist between students. Some students may behave reasonably OK on their own but when they’re with certain others, they don’t work well together. I know I was always being separated from my mates for talking. I see this as the teacher learning what inter-relationships exist and how to manage them. The action may be to separate them and all is fine. Or it may be to totally remove the bad one with no hope. Architecture is treated the same way. In terms of principles, we’re talking generally about anything that guides us. In general life you often hear things being done as a matter of principle. It justifies any particular action cause it links to how we wish to live our life. Architecture principles are very similar. These influence us to make the correct decision between two different options. A good architecture principle you’ll see just about anywhere is “Reuse, before buy, before build”. There’s no sense in reinventing the wheel, so it contains three questions to confirm we’re only building what we absolutely must as there’s no alternative. Design speaks for itself, and I believe it’s the real value add for EA. We can buy the most expensive best of breed software, or introduce plenty of best practices, but essentially it’s how we’re able to design a complete solution, or design the enterprise itself so it’s able to fulfil its vision. Another view of enterprise architecture is that it exists anyway. Even if we don’t model a single process or standardise any technology, the enterprise still exists, and it will still have a collection of information systems which have some accidental organisation. There’s a structure there, it’s largely unknown, not optimal, we’re not sure how it works, we certainly don’t know what’s wrong when it doesn’t work. But it is an enterprise architecture. This definition sort of fits with building architecture. You can see some beautiful architecture around Dubai without having to check the blue prints or seeing the AutoCAD 3D designs.
phi Φ - also known as the golden ratio, or golden number or section ( 1·618034) - has a very strong architectural foundation especially in nature. A vast amount of information has been collected showing an extensive number of natural forms which employ the proportion of phi Φ . No specific number recurs throughout life on Earth with such regularity. Nature uses this architectural pattern to arrange seeds on seed heads, petals on flowers, leaves around the stem, and as pictured here the growth proportions of shells. Even the DNA molecule, the program for all life, is based on these ratios. The Emirates Group Enterprise Architecture Framework has been named phi Φ to emulate how a single and true foundation can be reused throughout an environment to build upon success.
An EA Framework is the set of necessary building blocks and the relationships required to glue the blocks together. Due to the all encompassing definition of enterprise architecture there is substantial cross-over with other frameworks, tools, processes, and people. This is not an issue, EA as a tool can bring together many different efforts. Areas to highlight: EA is Strategy driven EA has different architectural layers Business Architecture modelling of the business operation - particularly interested in visions, goals, strategies, operations, processes, roles, and rules Information Architecture data design, flows, and lifecycles to create, capture, store, retrieve and dispose of information assets Application Architecture significant software, excluding software technologies, which supports business and information needs Technology Architecture supports the application portfolio, includes software technologies, hardware, and network support Some argue that Security Architecture is a 5 th layer. However, security is better considered a vertical consideration as it has requirements across each EA layer. Any changes requires an understanding of the current baseline Where organisations want To-Be becomes a Target architecture Strategies must exist to address those gaps which exist – which include transition plans There is an EA lifecycle, which can integrate with existing project and development lifecycles There are a number of enterprise architecture artefacts Technology standards mandate which technologies are to be used within the portfolio. Standards aim to promote the adoption of a common set of tools to maximise existing efforts and investment, as well reuse technology that is known to work well within the portfolio, or support the organisation’s strategic directions. Principles are general rules and guidelines that inform and support the way in which an organization sets about fulfilling its mission. They’re intended to be enduring and seldom amended. Best practices are known to produce the best outcomes. They are a result of existing success and years of experience invested to solving existing problems. The methods of interest are repeatable processes that help to optimise architectures. They are the means to create consistent, optimised and aligned deliverables.
Once components and their services need to be realized we have to make the decision of HOW to realize them. This is not the straightforward build versus buy decision: others interesting options come into the picture. “Transform”-ation uses a combination of techniques including business rules extraction to pull out a segment of functionality to be used independently for the realization of the component’s service. “Integrate” is the “wrappering” of legacy functionality to achieve functionality; integration is invocation-based. Subscription is based on the availability of a publish-subscribe model (in a message-oriented middleware context) in which a consumer subscribes to the services provided by the provider. One of the options is to outsource (e.g., Payroll) the functionality out to some other business. As the web services and Business to business integration becomes more prevalent, this option will also be considered for use on a wider basis. Subscribe and integrate (composite or simple integration (wrap)) are within an enterprise; integration is more oriented towards direct invocation whereas Subscribe is more oriented towards a publish-subscribe model. This is a matrix that maps components/services to how they are going to be realized as seen on slide 23 and 24.
Connecting Process Professionals
Enterprise Architecture Creating Alignment Christine Stephenson Emirates Group -IT
Managed and measurable IT services and measurement framework
Best practice processes (ITIL & CMMI) and structured approach
Redefine processes how IT interacts with the business
Re-align IT organisation to business
Repositioning of IT organisation within Group
Get close to the business Implement end-to-end IT service processes
Positioning and identity of IT within Emirates Group
High performance culture, ownership, leadership
Strategic sourcing model
Strategic direction and priorities driven by business
Framework for enterprise IT architecture and standards
IT governance framework People Project Scope
Design : Process Map IT Solutions and Customer Services IT Production IT Strategic Sourcing and Development IT Strategy and Architecture IT Architecture & Standards IT Strategy Portfolio Management Financial Management Quality Management Organisational Development IT Performance Measurement Security & Risk Management Business Info. Architecture Communication Governance Relationship Management Service Level Management Customer Relations Project Planning Proj. Monitoring & Control Risk Management Req. Mgmt & Req. Dev. Design & Development Program Management Product Integration Validation Verification Proj. Config Management Production Service Req. Management Inventory & Stores Mgmt Identity & Access Mgmt Capacity Management Availability Management Continuity Management Operations Management Release Management Configuration Management Incident Management Problem Management Change Management Security Management People Performance Management Training & Development People Life Cycle Resource Planning Recruitment Projects Supplier Relations External Supplier Mgmt
What is SOA? Agility Reusability Loosely Coupled Better Time To Market Design Philosophy Integration Architecture Style Higher Productivity ROI TCO Flexibility Visibility Methodology Services
Service Oriented Architecture (SOA) Service : Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit; provide weather data, consolidate drilling reports) Is a “black box” to consumers of the service Service Oriented Architecture (SOA) : is a way of thinking or an architecture style in terms of services and service-based development and the outcomes of services
SOA Service Lifecycle Service Identification Service Classification Service Litmus Service Specification Estimation / Funding Assign Ownership Service Development Quality Assessments Production Promote SLA Monitoring Service Portfolio Business Case Business Analysis Existing System Analysis Business Use cases Service Portfolio Business Modeling Requirement Specification System Specification Service Specification Application Architecture Design Models Service Framework Service Configurations Service Monitoring
Define system context (or business context) model.
Identify gaps with the current service portfolio
Estimate for SOA based development
Agree on ownership with stakeholders
Agree on the funding aspects
High Level Requirements
Service Portfolio Plan
Business Use cases
Updated Portfolio Plan
Identify the services ( at high level) , get funding and assign ownerships
All necessary Stakeholders
Project Portfolio Office
Service Modelling – Top down Business Analysis
SOA Service Modeling includes :
Classification & Catalogue
Top down domain decomposition approach for service modeling.
Service Modeling will be done during the requirement analysis and solution design phase
Service Identification Reserve Vehicle Check-out Vehicle Check-in Vehicle
Function Domain in this example is Rent Vehicle. Consider it as a black box
Identify Business Services – Why people are coming to the system ?
2 Reserve Vehicle Vehicle Delivery
Identify Business Processed
3 Source : IBM Fleet Management Promotions Management Customer Service Vehicle Availability Location Promotions Customer Profile Location Information Rentals & Reservations Vehicle Availability Reserve Vehicle Check Rates Check-In Vehicle Check-Out Vehicle Customer Profile Location Promotions Location Information Rent Vehicle Offered Service Consumed Service Rent Vehicle Rent Vehicle
Service Catalogue & Classification 1.2 Check-out Vehicle 1.3 Check-in Vehicle 0.Rent Vehicle 1.1.2 Make Reservation 1.1.1 Check Rates 1.2.1 Locate Reservation 1.2.2 Modify Reservation 1.2.3 Create Rental Agreement 1.2.4 Sign-out Vehicle from Lot 1.3.1 Locate Rental Agreement 1.3.2 Process Return Information 1.3.3 Process Payment 1.3.4 Return Vehicle to Lot 1.1 Reserve Vehicle 188.8.131.52 Get Location (pick-up/ drop-off) 184.108.40.206 Get Date / time (pick-up/ drop-off) 220.127.116.11 Choose Vehicle 18.104.22.168 Get Options Information 22.214.171.124 Check Vehicle Availability 126.96.36.199 Offer Rates For Selection 188.8.131.52 Confirm Rental Information 184.108.40.206 Get Customer Information 220.127.116.11 Get Payment Information 18.104.22.168 Confirm Reservation 22.214.171.124 Create Reservation
Catalogue all the services identified.
Classify them as
How do I decide which one is an application service - Service Classification Framework
Transactional Services, Query and Content Services, Data Service etc.
“ From all the candidate services, which ones should we expose?”
Not all candidate services should be exposed
Every implemented service has costs and risks
“ Service Litmus Test ” helps make exposure decisions
Source : IBM
Service Litmus for Rent A Car 126.96.36.199 Confirm Rental Information 188.8.131.52 Get Customer Information 184.108.40.206 Get Payment Information 220.127.116.11 Confirm Reservation 18.104.22.168 Create Reservation 22.214.171.124 Get Location (pick-up/ drop-off) 126.96.36.199 Get Date / time (pick-up/ drop-off) 188.8.131.52 Choose Vehicle 184.108.40.206 Get Options Information 220.127.116.11 Check Vehicle Availability 18.104.22.168 Offer Rates For Selection 1.2 Check-out Vehicle 1.3 Check-in Vehicle 0.Rent Vehicle 1.1.2 Make Reservation 1.1.1 Check Rates 1.2.1 Locate Reservation 1.2.2 Modify Reservation 1.2.3 Create Rental Agreement 1.2.4 Sign-out Vehicle from Lot 1.3.1 Locate Rental Agreement 1.3.2 Process Return Information 1.3.3 Process Payment 1.3.4 Return Vehicle to Lot 1.1 Reserve Vehicle = Service to be exposed Legend Source : IBM
Service Strategy Source : IBM Transform Integrate Subscribe Build Buy Time to decide on how we are going to get those services Outsource Integrate: Wrapping a legacy system’s function Build New Component Functionality (“Roll your own”) Transform legacy to enable functionality exposure for this service to reuse Buy : Integrate with third party product