Divide and conquer - Component based development with Mendix

Editor's Notes

• #2: Audience – application / information architects, ExpertsMessage – It is a well known fact that after about 10 years most applications become extremely hard to change. Improvements take a lot of time, and money. This seriously limits business agility. Many companies are turning to cloud, SOA and agile as a solution. The key is to build small teams around loosely coupled components. In this talk you’ll learn how Mendix can help you do this productively. We’ll share guidelines to successfully build large IT solutions from small components.you need to break up large apps in small components, easy to do in Mendix, aligns perfectly with agileMessage - No limit to size of Mx app
• #3: Partners and customers are increasingly asking us about building component based applications.How do we build applications by combining multiple small apps?
• #4: Main actor – enterprise application designers, solution architects, …Situation – Most green field applications have a good, modularized design, but after a number of years turn into spaghetti, hard to modify, and improveChallenge – Ensure long term adaptable and improvable software, that enables business agility, and software to support changing business requirements
• #5: After a number of years maintenance and enhancements, most software design turns into spaghetti
• #6: Usually the spaghetti is a result of necessary business shortcuts, due to limited time, resources and budget.Achieving business goals is key, but the overall architecture suffers
• #7: As technical debt builds up, it get harder and costlier to modify the software and support new business requirementsAt some point the software get so hard to change, and brittle that change is almost impossibleSmall changes in one place, cause regressions in unexpected waysI’ve seen this happen more than once with software about 10 years old
• #8: Then projects to refactor and improve the quality of the software is startedThe aim is to get back to modules and components, This is harder than expected, and often fails.
• #9: The biggest question around architecture isn’t “how do you design this?”, but “how do I create an enduring architecture?”.In the end we want to create an architecture/design right now, that will also ensure future business agility.Lets look at some examples that can show us how to create an enduring architecture
• #10: Next to Apple, Toyota is the most used example when explaining successful processes.When looking at architecture, Volkswagen may be a more apt exampleVolkswagen has had massive success with their platform architectureThis basically productizes components, new products are build using released, productized components
• #11: Turning components into products ensures clean separation of concernsMaking quickwin, shortcut solutions is a lot harderAt the same time, it turns projects into smaller problems, smaller teams, less coordination and less risk
• #12: Can this architecture work for IT?This model is very successful for many software companies:amazon, Netflix, …Key insights – servicesSmall teams create productized componentsServices with own roadmapServices architecture and cloud enables teams to operate independentlyAgain: separation of modules enforces by productized components Teams can own their roadmap by being able to independently deploy trough platform and service architectureYou build it, you run it (cloud self service enables teams to build, deploy and run)Build services, or be fired
• #13: Another aspect of working with components.Understand that you are not creating components part of a single project.People compare software architecture to building architecture, but this is not the correct comparison
• #14: Enterprise Architectuur is like city zoning: you define zones and responsibility of zones, but leave the actuall implementation of the zone to different teams/projectsA city lives longer than any of it’s parts, you frequently want to rebuild parts of the whole.
• #15: An example how this could work:Multiple teams, working on different componentsProductized components means, separate roadmaps, release calendars, etc
• #16: Teams release products, ready to be used by other teams.
• #17: Each team releases products at it’s own pace, suitable for the product/component
• #20: Building a end-customer product consists of integrating existing productized components, and adding a little bit that’s unique to the end-product
• #22: The project to release a new end-user product become a lot smaller, less teams to coordinate, less components to debug.Less risk, shorter project, faster time to market.
• #23: And more reuse of components
• #24: Key Insights: platform architectureTurning components into products ensures clean separation of concernsMaking quick and dirty solutions is a lot harderAnd turns projects into smaller problems
• #25: Enterprise architecture should focus on defining zones/modulesThe plumpingAnd the interfaces between the zonesLeaving the rest open creates agilityComponents, like zones, have their own lifecycles
• #26: Enterprise architecture should focus on defining zones/modulesThe plumpingAnd the interfaces between the zonesLeaving the rest open creates agilityComponents, like zones, have their own lifecycles
• #27: Every component should be able to determine its own lifecycle and release calendar
• #28: Components should be designed, implemented and run by separate, autonomous teams
• #29: And components should be able to choose the solution architecture best fit for the component
• #31: Productizing components is key to creating a resilient architecture, to avoid cross component shortcuts, and to promote reuse.Therefore, the Mendix appstore is a key element: it lets everybody focus on productizing components, and building composite solutions composed of productized components
• #32: App services enable you to quickly and easily expose functionality to other components
• #33: And to integrate it easily in other componentsFocus here is on ease of use.
• #34: App services work well between Mendix applications,To facilitate communication between heterogeneous components Mendix enables you to use webservices
• #35: Users need to be able to quickly and easily navigate between the different components and applications in your organization.This is the goal of Launchpad: give user easy access to the application they are authorized to use
• #36: Key pluming here is single sign on: a centralized store for authentication en authorization
• #37: A default app module is available so you can easily add the SSO functionality to your application
• #38: Small teams need to be able to design, build, deploy and run their application autonomously, this means that they need easy to use tools to deploy and monitor. The Mendix platform provides these tools through the Mendix portal: One place to easily deploy your application to the cloud, one place to monitor the well being of your application.
• #39: Unified monitoring dashboard helps teams run their application
• #40: Designing distributed Mendix systemsFocus on processFocus on autonomous apps, Minimize dependencies,Minimize data volume
• #41: How do you define your apps: what should the size and responsibility of the apps be?
• #42: How do you best handle communication between the apps
• #43: “There’s an app for that” best summarizes the responsibility of an App: focus on the activity of the user.It should provide a one stop shop for a specific activity within a business process
• #49: Start with whole processCluster by user/role/persona and activityUser activity: “There’s an App for that”Don’t focus on code reuse, it’s ok to re-implement similar pages in multiple apps
• #50: Determine goals, activities in business process done by users
• #51: Define apps for user activities. Goal is to have autonomous apps that support user activities.
• #53: The pace layer architecture as defined by Gartner is a good guideline for the lifecycle of your appsMost apps will focus on:Systems of innovation – short lived applications that enable you to innovate your businessSystems of differentiation – relatively short lived applications that enable you to differentiate from our competitionYou’ll probably have legacy systems for:Systems of records – this is where most master data and transactional data will eventually be stored
• #54: Apps will be implemented by independent teams, i.e., productized componentsEvery app can use an appropriate architecture
• #55: Using synchronous webservices to integrate apps results in one slow monolith. User interfaces become slow, as using webservices to get data introduces latency. Apps are not really autonomous, as you can use an app if other apps are not available. This becomes an uptime/availability nightmare. Even scheduled administration is hard.
• #56: Apps can be made more autonomous by pushing data from one app to the next when an activity/phase has been completed.Send course/large grained documents, transfer complete documents between activities (apps)Make sure app has all data needed for user activity before showing pagesPush from one activity app to next appsJIT pull when user opens appThis removes latency, and improve autonomy. Apps can work standalone for a while. Problem: Tightly coupled apps, apps have to know about the other apps.Adding extra apps/activities requires changes to other apps.No good way to maintain master data
• #57: Best way to decouple applications is by introducing an (event) busAll apps publish business events to the busYou can use existing cloud ESBs (iPAAS) like Mule, or use one of the ESBs created by a Mendix partner
• #58: Events can be received by all apps that needs it, for example to cache data needed by the application to work autonomously
• #59: Master Data ManagementEvents can be used to update master dataData can be cached in other apps, but all master data should have one owner
• #60: Another useful strategy: create a separate, autonomous, data store.Decrease dependency on legacy solutions to manage master data,Create a way to replace those legacy solutionsApps can subscribe to data change information with the data store.