Anzeige

Who needs EA… when we have DevOps?

Cloud Architect - IBM Cloud Software at IBM um IBM
7. Mar 2016
Anzeige

Más contenido relacionado

Presentaciones para ti(20)

Similar a Who needs EA… when we have DevOps?(20)

Anzeige

Who needs EA… when we have DevOps?

  1. Who needs EA… when we have DevOps? Jeff Jakubiak – Architect / DevOps Evangilist @JeffJakubiak
  2. Enterprise Architecture Do we need it?
  3. Do we need Enterprise Architecture? 3
  4. 4 Insufficient strategic spend & business agility • Cost – 80/20 budget trap – Maintenance and operations consumes a significant % of a declining IT budget, limiting funds available for new initiatives • Business agility – Brittle and tightly coupled architectures, unwarranted complexity, and technology proliferation • Strategic planning – Inability to actively plan strategic initiatives; Cloud, Mobile, Compliance, M&A, and Divestitures • Risk / supportability – Skills erosion, baby boomer retirements, and aging technology 4 The problem is a often due to hyper-focused attention on siloes of the enterprise
  5. What is Enterprise Architecture? 5 “The Enterprise Architecture discipline defines and maintains the architecture models, governance, and transition initiatives needed to effectively co-ordinate semi-autonomous groups towards common business and/or IT goals” 1 “The Enterprise Architecture discipline defines and maintains the architecture models, governance, and transition initiatives needed to effectively co-ordinate semi-autonomous groups towards common business and/or IT goals” 1 1 - Enterprise Architecture in the era of On-Demand, IBM Academy of Technology Study, October 2004 2 - Short form, Gartner Defines the term ‘Enterprise Architecture’, Anne Lapkin, Gartner, July 12, 2006 “Enterprise architecture is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key principles and models that describe the enterprise's future state and enable its evolution.” 2 “Enterprise architecture is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key principles and models that describe the enterprise's future state and enable its evolution.” 2 Similar definitions, consistent intentSimilar definitions, consistent intent IBM: Gartner:
  6. EA is a Cross-Domain Discipline 6  Capture, evolve, analyze and communicate business architecture aspects  E.g. capabilities, portfolio, prioritization, etc  Mapping them to current and future technical architecture aspects  Process, Applications, Systems, Data, Network etc  In a way useful for both decision support and execution guidance  “actionable architecture” Applications & Systems Information & Data Strategy Business Network & Infrastructure Programs & Projects “We can’t solve problems by using the same kind of thinking we used when we created them.” – Albert Einstein
  7. How Can EA Help Your Business? 7 Manage Outsourcing  Customer: Req’ts, specs, testing  Vendor: Actual architectures Manage Outsourcing  Customer: Req’ts, specs, testing  Vendor: Actual architectures Satisfy Mandated Compliance  Regulatory or contractual  DoDAF, TOGAF, FEA (iRMA), etc. Satisfy Mandated Compliance  Regulatory or contractual  DoDAF, TOGAF, FEA (iRMA), etc. Pass an Audit  Architecture & business transparency  Repeatable, documented Pass an Audit  Architecture & business transparency  Repeatable, documented Visualize and Communicate  Beyond basic drawing tools Visualize and Communicate  Beyond basic drawing tools Understand What You Have  Current state analysis  Your intellectual property and Assets Understand What You Have  Current state analysis  Your intellectual property and Assets Improve What You Have  Find incremental improvements  Manage business transformation Improve What You Have  Find incremental improvements  Manage business transformation Manage the Portfolio  Applications/Products  Improved reuse across organization Manage the Portfolio  Applications/Products  Improved reuse across organization Return on Assets  Leverage elements across subsystems and product lines Return on Assets  Leverage elements across subsystems and product lines Manage Packaged Applications  Integrate with rest of architecture Manage Packaged Applications  Integrate with rest of architecture Common Project Starting Points  Initiate new projects from a common starting point based on an EA model Common Project Starting Points  Initiate new projects from a common starting point based on an EA model
  8. Enterprise Architecture The problem with a classic approach
  9. Common Perspectives • Project Teams – “What is the EA team is doing for us?” – “These reference architectures are nice but we need to change XYZ.” – “The EA team is just slowing us down!” – “We don’t need a traffic cop!” • EA Team – “Are we making the right IT investments based on business priorities?” – “Technical debt is killing the ability of IT to be agile.” – “Why doesn’t the environment look like the one we approved?” 9
  10. There is a need for adjustment • Project Teams – Must realize the impacts of standards deviations on technical debt • EA Team – Must make it easier for project teams to understand where to start – Must become an enabler for project teams to move faster 10
  11. DevOps An understanding
  12. Costly, error prone manual and duplicative processes delay innovation and impact competiveness CHALLENGES Risk of instability due to managing multiple configurations and versions Slow deployment to development and test environments leave teams waiting and unproductive CHALLENGES Operations/ Manufacturing & Support Software & Product DevelopmentCustomers Line of Business/ Product Managers What is DevOps Trying to Solve?
  13. 13 Focus of DevOps is Removal of Waste
  14. DevOps in an Enterprise 14 Collaborative DevelopmentCollaborative Development Continuous Release and DeploymentContinuous Release and Deployment Continuous TestingContinuous Testing Idea Market DevOpsDevOps Continuous Business Planning Continuous Business Planning Continuous MonitoringContinuous Monitoring Lean and Agile principles Operate Target Customer Develop / Test Service Developer/Tester Steer Business Owner Deploy Service Operations Continuous feedback and Optimization
  15. Enterprise Architecture + DevOps A better way
  16. Where Does EA Fit? 16 Collaborative DevelopmentCollaborative Development Continuous Release and DeploymentContinuous Release and Deployment Continuous TestingContinuous Testing Idea Market Continuous Business Planning Continuous Business Planning Continuous MonitoringContinuous Monitoring Lean and Agile principles Operate Target Customer Develop / Test Service Developer/Tester Steer Business Owner Deploy Service Operations Continuous feedback and Optimization DevOpsDevOps Enables Continuous Business Planning Enables Continuous Business Planning Adjusts Patterns Based on Performance Adjusts Patterns Based on Performance Develops Standards and Frameworks Develops Standards and Frameworks Creates Executable Environment Patterns Creates Executable Environment Patterns Ensures Technical Debt Addressed in Release PlansEnsures Technical Debt Addressed in Release Plans
  17. Visualize components supporting enterprise strategies & goals. Visualize impact of projects and initiatives. Visualize dependencies upon specific infrastructure assets. Business Processes Applications Data IT Infrastructure Orgs & People Enterprise Strategies & Direction Business Processes & Services IT Infrastructure & Services Projects & Initiatives 17 Visualize the Enterprise for Better Decisions
  18. Release Planning and Management •Enterprise Calendar •Release Process Checklist •Environment Reservation Effective Change and Risk Management •ALM system integration •Impact Analysis Continuous Delivery with Automation / Auto-Progression •Deployment automation integration Visibility and Control •Pipeline View •Federated Dashboard •Segment Dependency Graph Include Technical Debt in Release EA team must provide input into release plans and have clear visibility
  19.  The adoption of DevOps == increased velocity of application delivery  Puts pressure on the infrastructure to respond more quickly  Software Defined Environments enable you to capture infrastructure as a software artifact Application Changes Infrastructure Changes Provisioning Becomes the Bottleneck
  20. Provide portability across heterogeneous virtual datacenter, private and public clouds 3. Portable across different virtualized infrastructure Assemble multi-tier application environments and define auto-scaling policies to meet operational needs. 2. Assemble multi-tier and scalable environment blueprints 1. Create stacks Load Balancer Web Servers App Servers Database Servers Firewall Application Compute, Storage, Network Configuration OS / Platform Image Middleware Configuration Middleware Policies Describe full stack environments using infrastructure building blocks like Images, middleware scripts, and application code VMware vCenter Private PublicVirtual Datacenter 20 Create Executable Patterns
  21. 21 Compute | Storage Compute | Storage OSOS Packaged Software Packaged Software ApplicationApplication MiddlewareMiddleware Compute | Storage Compute | Storage OSOS Packaged Software Packaged Software MiddlewareMiddleware NetworkNetwork Cloud Management Deployment Automation Capabilities Security, approvals and promotion of applications through different stages. Automated Deployment of all components of Application (DB, Web, Mobile) Automated Middleware configuration required for Application Deployment Discover MW Configuration for WAS Virtual System Pattern Creation and Provisioning Self Service Portal for VM Provisioning Image Library (Search / Compare, Versioning, and SW Stacks) Basic Single Image Composition, Manipulation of images with pre-configured middleware Multi-tenancy, Isolation, Rapid , Scalable Provisioning Cloud Administration Environment Provisioning Application Flexibility & Pattern Reuse
  22. Benefits Summary of EA + DevOps • Ability to visualize relationships across EA domains allows organizations to understand decision implications outside siloes – Business focused decisions – Ripple effect of choices • Inclusion of EA in the scope of DevOps enables development teams – Clear understanding of reference architectures / patterns in early phases – Provides a natural context for inclusion of IT governance & collaboration • IT infrastructure models created as executable patterns of EA – IT project teams gain the ability to have on-demand environments – Environments do not need to be checked for standards – Positions EA as enabler versus “traffic cop” 22
  23. Notices and Disclaimers 23 Copyright © 2016 by International Business Machines Corporation (IBM). No part of this document may be reproduced or transmitted in any form without written permission from IBM. U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM. Information in these presentations (including information relating to products that have not yet been announced by IBM) has been reviewed for accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM shall have no responsibility to update this information. THIS DOCUMENT IS DISTRIBUTED "AS IS" WITHOUT ANY WARRANTY, EITHER EXPRESS OR IMPLIED. IN NO EVENT SHALL IBM BE LIABLE FOR ANY DAMAGE ARISING FROM THE USE OF THIS INFORMATION, INCLUDING BUT NOT LIMITED TO, LOSS OF DATA, BUSINESS INTERRUPTION, LOSS OF PROFIT OR LOSS OF OPPORTUNITY. IBM products and services are warranted according to the terms and conditions of the agreements under which they are provided. Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without notice. Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual performance, cost, savings or other results in other operating environments may vary. References in this document to IBM products, programs, or services does not imply that IBM intends to make such products, programs or services available in all countries in which IBM operates or does business. Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not necessarily reflect the views of IBM. All materials and discussions are provided for informational purposes only, and are neither intended to, nor shall constitute legal or other guidance or advice to any individual participant or their specific situation. It is the customer’s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer’s business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or represent or warrant that its services or products will ensure that the customer is in compliance with any law
  24. Notices and Disclaimers Con’t. 24 Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products in connection with this publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. IBM does not warrant the quality of any third-party products, or the ability of any such third-party products to interoperate with IBM’s products. IBM EXPRESSLY DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. The provision of the information contained h erein is not intended to, and does not, grant any right or license under any IBM patents, copyrights, trademarks or other intellectual property right. IBM, the IBM logo, ibm.com, Aspera®, Bluemix, Blueworks Live, CICS, Clearcase, Cognos®, DOORS®, Emptoris®, Enterprise Document Management System™, FASP®, FileNet®, Global Business Services ®, Global Technology Services ®, IBM ExperienceOne™, IBM SmartCloud®, IBM Social Business®, Information on Demand, ILOG, Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower, PureAnalytics™, PureApplication®, pureCluster™, PureCoverage®, PureData®, PureExperience®, PureFlex®, pureQuery®, pureScale®, PureSystems®, QRadar®, Rational®, Rhapsody®, Smarter Commerce®, SoDA, SPSS, Sterling Commerce®, StoredIQ, Tealeaf®, Tivoli®, Trusteer®, Unica®, urban{code}®, Watson, WebSphere®, Worklight®, X-Force® and System z® Z/OS, are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at: www.ibm.com/legal/copytrade.shtml.
  25. Thank You Your Feedback is Important! Access the InterConnect 2016 Conference Attendee Portal to complete your session surveys from your smartphone, laptop or conference kiosk.

Hinweis der Redaktion

  1. Almost every customer we talk to face these problems, which is the focus of APM to address: Too much money is spent on maintenance and operations. As the graphic illustrates, we need to reduce cost of operations and maintenance, so we can free up money for innovation or for savings. Even if you have funds, you can not develop capabilities at the speed of business, among others due to brittle architectures and technology proliferation. Many CIOs struggle with how to best leverage the Cloud, how to enable their applications for Mobile devices, how to address compliance mandates, or how to address M&A or divestitures. Which application should I move to the Cloud first? How do I reason about which applications to keep and which not to keep after a merger? Another key problem is risk related to skills (people with critical skills about to retire), or aging technology. Phil Murphy from Forrester has done a lot of great reports on APM, and recently interviewed 35 customers to learn about what they are doing around APM, and we see some results here: A large UK bank initiated its APM effort to take a 90:10 ratio for run-the-bank / grow-the-bank down to a more reasonable 40:60 ratio. Dell shifted its maintenance-to-innovation ratio from 80:20 to 50:50 In IBM’s initial APM effort, we reduced the number of applications from 15,000 to 6,800, a reduction by more than 40%, and reduced maintenance spend by more than 40%, including through changes to how we sourced applications. <Application Portfolio Management: From assessment to transformation, by IBM Global Services, http://www-935.ibm.com/services/uk/igs/pdf/esr-application-portfolio-management-from-assessment-to-transformation.pdf > So, APM can offer a solution to these problems, as we will see. *Data chart is from IBM (VP of marketing)
  2. This slide is a textual summary of the key waste areas related to software release and deployment.
  3. D – Show how to visually show relationships within the explorer diagram (Explorer – “Impact Analysis”) D – Drill into child relationships (Enterprise Direction – “Corporate Office”)
  4. This slide summarizes key capabilities of UrbanCode release. Better Release Planning and Management – new capabilities to ensure that everyone is on the same page with release events Effective Change and Risk Management – Integration with RTC and the ability to asses Impact of a change allow users to better understand the readiness for releases as well as develop a confidence level in a particular release event. Integration with UC Deploy – see next slide Increased Visibility and Control – The pipeline view allows users to see at-a-glance stance of all environments associated with an application in a release. Know immediately what version is where, what the status is and make/schedule changes as necessary. The federated dashboard gives high-level visibility into multiple release events --- including estimated times of completion. In addition, the ability to see dependencies across releases provides for better decision making and control.
  5. There are a lot of things that go into making an application work in the cloud. Ideally we want to have all these things working together and treat them as a unit. That is the idea of working with a full-stack. We would also really like to be able to leverage that stack in whatever kind of cloud we happen to be working with – public, private or hybrid, and we want it to work with different vendors (IBM, AWS, VMWare) If we can (1) design the entire stack (the Operating system, parameters, middleware, configurations and applications) all together and then (2) use that as a blueprint we can then (3) make that blueprint usable across different types of cloud environments.
Anzeige