15. EA Φ Framework Quality Management Business Analysis Configuration Management Project Management IT Mgmt / Customer Service Service Management Software Development Strategic Sourcing
16.
17.
18. 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
19. What is SOA? Agility Reusability Loosely Coupled Better Time To Market Design Philosophy Integration Architecture Style Higher Productivity ROI TCO Flexibility Visibility Methodology Services
20. 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
27. 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
28.
29.
30.
31.
32.
33. Service Litmus for Rent A Car 1.1.2.1 Confirm Rental Information 1.1.2.2 Get Customer Information 1.1.2.3 Get Payment Information 1.1.2.4 Confirm Reservation 1.1.2.5 Create Reservation 1.1.1.1 Get Location (pick-up/ drop-off) 1.1.1.2 Get Date / time (pick-up/ drop-off) 1.1.1.3 Choose Vehicle 1.1.1.4 Get Options Information 1.1.1.5 Check Vehicle Availability 1.1.1.6 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
34. 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
35.
36. SOA Do you want to go further down or come up?
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.