Strategies for efficient Delivery

Transcription

1 überraschend mehr Möglichkeiten! Strategies for efficient Delivery with APIs, Containers, Microservices, Sven Bernhardt, Danilo Schmiedel

2 OPITZ CONSULTING - A success story since 1990 Our Mission: Help organizations to leverage the possibilities of digitalization to be different, better and faster than their competitors Owner-Managed company with 400+ consultants 11 locations in Germany and Poland About us Danilo Schmiedel Sven Bernhardt Managing Consultant Lead for Competence Center Cloud Solution Architect Technical Lead for API Management Seite 2

3 Scenario #3: Innovation Seite 3

4 Often encountered in today s IT system landscapes Lack of innovation Missing knowledge Lack of integration Decreasing benefit Increasing costs Lack of maintainability Decreasing data quality Seite 4

5 New ways on how to develop applications are needed to manage agility (Bi-modal IT) Customer-specific solutions New ideas Innovation Systems of Innovation Better ideas Differentiation Systems of Differentiation Typical ideas Standardization Systems of Record Standard Software solutions Based on Pace Layered Application Strategy, Gartner 2012 Seite 5

6 Lots of buzzwords, concepts and techniques, but how to find a beneficial mixture for Next-gen app development? Monolithic applications Microservices Containers Docker API Management Continuous Integration Continuous Delivery SOA Integration Cloud Seite 6

7 How to get there? Seite 7

8 How to make it wrong? Risk 1 Risk 2 Risk 3 Risk 4 Risk 5 Risk 6 Risk 7 Risk 8 Risk 9 Risk 10 The initiative / program is a collection of individual IT projects Requirements are just IT-driven Unconditional belief in the platform vendors Faith in error-free, unchangeable planning and roadmap Lack of coordination between Business and IT Start without clear goals and benefits Underestimating efforts for changing legacy applications Missing change management Lack of coordination with other IT-related initiatives Insufficient perception of complexity Seite 8

9 Define the goals Seite 9

10 OC Lab Download: Seite 10

11 Management Business Analytics Monitoring Security Solution architecture for the use case based on OMESA reference architecture Open Modern Enterprise Software Architecture (OMESA) User Experience Credits to Luis Weir, Capgemini Web Mobile Device Single Purpose API Multi-Purpose API Semi-decoupled Service Implementation Fully-decoupled Monolithic System Shared Storage Persistence Event Store Registry Non-shared Storage Seite 11 Seite 11

12 OMESA reference architecture Open Modern Enterprise Software Architecture (OMESA) Credits to Luis Weir, Capgemini Seite 12

13 Main Objectives of OMESA All in all, OMESA has 4 main objectives: 1. To deliver a modern and enterprise-wide software reference architecture suitable to combine existing" with the "new" 2. Provide guiding principles and definition of terms to ensure the architecture can be interpreted and applied 3. Deliver a vendor agnostic capability model that can add tangible business value to organizations 4. Bring back architectural best practices (based on real live experiences) into modern solutions that are suitable for organizations of any size and industry Seite 13

14 OPITZ CONSULTING - A success story since 1990 Mission: Help organizations leverage the possibilities of digitalization to be different, better and faster than their competitors Owner-Managed company with 400+ consultants at 11 locations in DE and PL Revenue 2016: 47 Mill. About us Danilo Schmiedel Sven Bernhardt Managing Consultant Lead for Competence Center Cloud Solution Architect Technical Lead for API Management Seite 14

15 We have a monolithic backend application. We would like to slice the application into small functional building blocks. Our challenge is to find the right size of these building blocks according to our business requirements. Energy (E-Mobility) / Product Owner Seite 15

16 One approach to find the right service design Domain Decomposition Derive services and respective data objects from your business processes, which are here expressed in a standard notation like BPMN Production Logistics Selling Billing Seite 16

17 But: The Domain Decomposition approach is not trivial Very formal approach Knowledge with respect to the modelling notation (e.g. BPMN) is needed and everyone needs to understand the model Might be time-consuming Disagreements regarding the business process flow Discussions about the modelling style (Is it correct in the sense of the spec?) Danger to model all process variants and edge cases (Lost in details) Need to know business domain and processes Risk to loose workshop participants, who might have important information Seite 17

18 Event storming as a more agile and lightweight approach for identifying services and domains Event storming was invented by Alberto Brandolini (2013) Ingredients: Unlimited modelling space Sticky Notes Markers People from different organizational areas and levels (6-8 people) Facilitator Key terms: Event Command and External system Aggregate Bounded Context Seite 18

19 Source: OPITZ CONSULTING 2017 Slide 60 Seite 19

20 Event Storming is a good approach for breaking up complex business domains to manageable services Informal and easy approach, because there are no formal rules like standard notations The right people are talking about their business domain, so it is ensured that all questions can be answered Since it is not strictly formalized and everyone is invited to participate, the approach is fun But, attention Good facilitation skills are needed and Workshop participants have to get involved Seite 20

21 We have a historically evolved system. Today it is hard for us to extend the system with new apps, chatbots and location-based services because of missing APIs. Professional Services / Head of Business Development Seite 21

22 Current situation: Monolithic custom-implemented ERP application prevents innovation Complex system without public APIs Controls whole business use cases Difficult to maintain und extend Fragile solution (each change can lead to inconsistency) Needs to stay robust and free from defects Oracle Forms Client Oracle ADF Application Seite 22

23 Implementation platform overview The big picture Service Implementation (fuly-decoupled) {json} APIs {json} Validation {json} Authentication Throttling Container CS Continuous_integration_delivery Routing Persistence Filtering Developer CS API PlatformCS Seite 23

24 Modernization based on Oracle Cloud Services {json} APIs Validation {json} Service Implementation (semi-decoupled) Service Implementation (fuly-decoupled) Developer CS Authentication Connect Continuous_integration_delivery {json} Throttling {json} Transform Routing Filtering Orchestrate Container CS Integration CS API PlatformCS SOA CS Java CS Seite 24

25 We are in the process of establishing a centralized communication platform. It is based on microservices but our development performance is not as good as we expected. The available infrastructure does not scale. The Developers are not very much motivated because of very slow feedback cycles. Retailer / Head of IT Governance Seite 25

26 Agile software delivery is hard without a approach Fixed set of technologies (e.g. not Java, Node.js and.net), which might block developers to use the most appropriate technologies No approach because Software delivery is the responsibility of another team in a different organizational unit; discussions with them are hard A consistent approach is needed to be able to establish new services efficiently within a short time-to-market Devops.svg.png Seite 26

27 It s not a only technical thing; being adaptable and agile concerns the whole organization Changeability is an essential prerequisite for becoming more agile and to promote innovation Moving forward is basic for prospective success New collaboration approaches are needed to improve time-to-market It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change. (Charles Darwin) Seite 27

28 Continuous Delivery and Deployment for complex Microservice architectures Wercker Create custom CI/CD pipelines Chain & trigger pipelines to create complex workflows Speed up tests by running them in parallel Source: Seite 28

29 We are an enterprise company. Software development is usually done by following a waterfall approach. Our development cycles are too long due to organizational barriers and rules. On the other hand we have to come up with new ideas and innovations to improve our daily work. Manufacturer / CIO Source: Source: Seite 29

30 Be brave and promote innovation! PoC Pilot MVP Initiate digital innovation labs for trying new ideas and technologies and leverage from PoCs, Pilots, MVPs Involve those who are affected at an early stage and ask for "advice" Earlier and quicker feedback on feasibility and acceptance Change the attitude: From suit to hoodie wearer Change the mentality: Be ready to fail, adjust and try again. Seite 30

31 Get support from Outside Innovation Lab as a Service (ILaaS) Guru Co-working space From office space, support from experts, coffee and water => all inclusive for a monthly fee Example use cases: Supporting and optimizing existing processes with Mobile apps Hololens for supporting the production process GPS tracking use cases Source: Source: Seite 31

32 ILaaS Approach Choose manageable use case Fixed iteration length (approximately 4 weeks) Development ends with a Minimal Viable Product (MVP) Define basic solution architecture Review Solution not applicable? Withdraw Re-/Define use case Feedback Choose implementation platform & approach Staff team Technicians (Implementors / Architects) Business stakeholders Feedback Implement MVP Define solution architecture Feedback Implement MVP Review Staff team Choose platform Feedback Feedback Seite 32

33 API Management is the key to ensure agility Finalized definition of the single-purpose APIs on day two in a collaborative way with Apiary Independent development of Mobile app, Mobile Backend, Backend Service and API Problem: Connectivity to the backend system, because Firewall changes took too long (4 weeks project duration, connectivity was available in week 3) Development team was not blocked because implementation of the mobile app was done against the Mock Server functionality in Apiary Phase 1 Phase 2 Modernize Your IT Landscape with API-Driven Architectures Seite 33

34 It s all about change! Seite 34

35 Plan you next steps Use of Microservice architecture Decoupling Backends from Frontends 0% Microservices 0% BfF Usage Microservices Backend for Frontend (BfF) 100% Microservices 100% BfF Usage Use of API Management 0% API-Mgmt. API-Management 100% API-Mgmt. Establish a approach 0% 100% Implement an application platform 0% Platform Application platform 100% Platform Seite 35

36 Summary Understand the business goals and design properly (e.g. Event Storming) API Management is the key to ensure agility Ability to change, which means the way how architectures and applications are designed and implemented collaboration between different stakeholders happens how processes and procedures are used Attitude: From suit to hoodie wearer Mentality: Be ready to fail, adjust and try again Microservices and belong together and both are not just tools Seite 36

37 Q & A Seite 37

38 überraschend mehr Möglichkeiten! In case of any questions, please contact us! Danilo Schmiedel Managing Consultant Solutions Oracle ACE Director OPITZ CONSULTING Deutschland GmbH Tempelhofer Weg 64, Berlin, Germany Phone: Sven Bernhardt Solution Architect Oracle ACE OPITZ CONSULTING Deutschland GmbH Kirchstrasse 6, Gummersbach, Germany Phone: OPITZCONSULTING opitzconsulting Seite 38

39 500+ Technical Experts Helping Peers Globally 3 Membership Tiers Oracle ACE Director Oracle ACE Oracle ACE Associate bit.ly/oracleaceprogram Connect: oracle-ace_ww@oracle.com Nominate yourself or someone you know: acenomination.oracle.com