1 / 36

Björn wallin

Björn wallin. Integration governance.

clark
Download Presentation

Björn wallin

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Björn wallin Integration governance

  2. In this session Björn Wallin will talk about the importance of a governed approach to integration. He will highlight governance to enable progress in the integration maturity model and Center For Enablement (C4E) as means for even further progression to a business driven level. Examples of instruments such as guidelines, API-strategy, documentation concerns etc will be given. ICSS Program

  3. MATURITY MODEL Integration OPTIMIZED MANAGED DEFINED DEVELOPING INITIAL

  4. MATURITY MODEL Integration OPTIMIZED MANAGED DEFINED DEVELOPING INITIAL

  5. MATURITY MODEL Integration OPTIMIZED MANAGED DEFINED DEVELOPING INITIAL • AD HOC • Sprawling • Individual initatives • Builds technical debt • Lack of overview • What? • Why? • How? • Value?

  6. MATURITY MODEL Integration OPTIMIZED MANAGED DEFINED DEVELOPING INITIAL IT-driven Integration platform / ESB API-Gateway Monitor technology ICC – Centralized Cost control

  7. MATURITY MODEL Integration OPTIMIZED MANAGED DEFINED DEVELOPING INITIAL Governance! Strategies Reference architecture Dev-ops and Automation Monitor data flows

  8. MATURITY MODEL Integration OPTIMIZED MANAGED DEFINED DEVELOPING INITIAL Business driven! Goverance as enablement C4E / Distributed API Economy Application network / resuse Time to market

  9. MATURITY MODEL Integration OPTIMIZED MANAGED DEFINED DEVELOPING INITIAL Intelligence driven! New business and delivery models KPIs and metrics Analytics

  10. Integration governance What is it all about? Applying strategies, polices and guidelines as instruments to get the right things done in a proper and effective way. Assure architectural alignment, quality and security Reduce complexity, cost and technical debt Getting synergies and making reuse happen, speeding up And the classical: Bridging the gap between IT/technology and enterprise/business

  11. Integration governance How to make it happen? Organisation that clearly defines responsibility and mandate for integration governance Typically an Integration Competency Center (ICC) Aka Center Of Excellence (COE) Different ICC operating models (derived from Schmidt & Lyle) Offering expertise and best practices is the foundation More or less (de)centralized Small/big, may include developers and development resources More or less oriented towards self service, Center For Enablement (C4E) at a high maturity level Central services Self service Shared services / Distributed C4E

  12. Integration governance ICC Lead and support integration projects and/or provides expertise and guidance Provides best practices, polices and guidelines for integration Assess and select integration technology and approaches Have a holistic perspective and pay attention to synergies, conflicts and system life cycles to optimize integration investments Big company = big ICC, small company small ICC (one person!?) Business and technology insight Potential risks/limitations: Centralization can make information less accessible Becomes development bottleneck Becomes to rigid

  13. Integration governance C4E Shift of focus to enablement and evangelism API-driven Promotes the consumption and reuse of projects and assets Provides tools, API:s and templates shared via portals for self service Encourages not only to utilize assets but to add and improve them as well, scaling the network effect. Intended output: Improves speed in development/integration as well as in best practices Enables decentralization and integration projects driven by line of business Faster time to market More reusable assets Improved business value by taking advantage of network of assets

  14. Borrowed from Mulesoft Requires API:s for system access More asset consumers Decentralized Self service

  15. Borrowed from Mulesoft

  16. Borrowed from Mulesoft

  17. Borrowed from Mulesoft Application network – continuously more and better API:s and applications

  18. MATURITY MODEL Integration OPTIMIZED MANAGED DEFINED DEVELOPING INITIAL Business driven! Goverance as enablement C4E / Distributed API Economy Application network / resuse Time to market

  19. API Economy APIs Information Asset Owner Products Products Provides access to assets Data Consumers APPs End Consumer Use applications and artifact and provide value to developers, APIs and assets Delivers rich customer experience

  20. API Economy Slow Speed Fast Speed RENOVATE INNOVATE

  21. API Management C4E and API Economy - Recapitulate: Requires API:s for system access More asset consumers Self service Requires API Management!

  22. API Management solution API Developer portal • Customer engaging • Self enrollment • Self service • Easy to use and find • Self explanatory API Management • Design • Development (HL) • Publishing • Scalability • Monitoring • Analysis • Monetization API Gateway • The Runtime • Enforcing security • Executing policies (eg Rate Limiting) • Doing mediation • Facilitates Logging

  23. In this session Björn Wallin will talk about the importance of a governed approach to integration. He will highlight governance to enable progress in the integration maturity model and Center For Enablement (C4E) as means for even further progression to a business driven level. Examples of instruments such as guidelines, API-strategy, documentation concerns etc will be given. ICSS Program

  24. Integration governance Instruments - Best practices, guidelines, etc Integration strategy Goals Organization Economy On prem / Hybrid / Cloud Reference architecture Service registry / API Catalog (API-mgmt) Developer portals (API-mgmt) Information models Masterdata model

  25. MATURITY MODEL Integration OPTIMIZED MANAGED DEFINED DEVELOPING INITIAL

  26. Integration governance Instruments - Best practices, guidelines, etc Guidelines API-design Naming conventions Message formats Integration patterns Security Logging & Monitoring Testability Continuous integration Automated test and deploy Etc..

  27. Integration governance Integration and/or API catalogs - Documentation concerns Need an overview of all integrations and API:s Dependencies Support different stakeholders: Consumers Owners Developers Different tools: Word documents (please, no) Wiki (much better) Integration landscape tools (e.g. Nodinite, Pryorit) or Graph databases (e.g. Node4J) Define the documentation model What is an integration? Distinguish between API and implementation

  28. Integration governance So, what do we mean with “one integration”? Let’s start simple: if we connect two systems we have one integration

  29. Integration governance So, what do we mean with “one integration”? Two integrations

  30. Integration governance So, what do we mean with “one integration”? But now?

  31. Integration governance So, what do we mean with “one integration”? Data type/function and data flow directions are other aspects

  32. Integration governance So, what do we mean with “one integration”? API:s is yet another aspect

  33. Integration governance So, what do we mean with “one integration”? And we need to distinguish between APIand implementation (application) Not affected Client Client API Stable Implementation Changeble System System Add/remove/update Implementation API/Interface

  34. Integration governance API vs Implementation Different purpose and audience API-documentation = interface specification Initially for developers of implementation Primarily and over time, for users/consumers of the API Application documentation = Technical description For developers/maintenance Versions of API and application is not (doesn’t have to) be synchronized Version 2.3.1 of the application may still implement version 1.0 of the API

  35. Integration governance Integration and/or API catalogs - Documentation concerns Need to cover Integrations (flows) Define what it means and granularity Shows the dependencies API:s / Interfaces Implementations Decide a manageable level of complexity and coverage!

  36. #TTTT Together To The Top #TTTT

More Related