The unfortunate story of Joe the Business Analyst
Joe is a business analyst at Acme Bank, a company that uses a certain composition platform. He is composing a mobile application for customers to check their account balance. Looking for a log in screen that authenticates customers, he searches the platform’s marketplace of bricks for “login authentication”. What he gets back is five or six different bricks with very technical or redundant names like “$$Authentication”. It doesn’t look like any of them does what he needs, so he builds his own login screen brick. As he shows his work-in-progress to his colleague Tina, she says, “But Joe there was already a brick that does exactly this in the marketplace!” Joe realizes he has just wasted his time reinventing the wheel.
After much struggle he finally finishes his prototype. When he comes back to it the next day, he finds this:
The whole thing is broken! What happened? What he doesn’t know is that Tina, who was just checking out his app in the platform last night, accidentally broke a connector in his login screen brick. Why did this series of unfortunate incidents happen? Because of three essential flaws in the marketplace that Acme Bank overlooked when selecting a composition platform vendor.
What we know so far
The Composition Platform is like the Lego set where an enterprise can assemble bricks of business capabilities, such as live temperature readings from IoT sensors embedded in a container of sensitive pharmaceuticals, into complete business solutions.
The 5 main pillars of a best-of-breed composition platform are
- A Marketplace: a catalog of packaged business capabilities or “bricks”
- Composition: assembling bricks into more complex capabilities or full-fledged application
- Integration: populating the Marketplace catalog with your company’s data and services
- Development: Coding to create custom capabilities such as data or a service directly within the platform
- Operations: running the compositions in a production environment
Any composition platform worth considering must come with a minimum set of packaged capabilities that are robust, well-documented, and ready to use. At Olympe we call these packages of capabilities “bricks”. A brick could be anything from a simple a+b sum function to an SAP P.O. approval application.
The composability and reusability benefits of a composition platform are proportional to the breadth of capability bricks available out-of-the-box and which therefore do not need to be coded by the enterprise’s IT team. The platform vendor should usually provide the low-level bricks to manage data, REST APIs, and user interfaces that can function with any device and platform. The enterprise IT team would use those bricks to build custom bricks for its needs, such as connector bricks for an in-house live market analysis service. The custom bricks would join the marketplace and become available for the whole organization to reuse as often as they like. This is how over time the Marketplace becomes more and more valuable to your organization. A good marketplace should be designed such that you feel comfortable growing it without being locked-in to that vendor.
Organization and structure are essential
Like with any catalog, and especially a growing, evolving one, it is essential that the contents of the Marketplace be well classified and structured in order to ensure it is usable. From all the ways I have explored to structure bricks, I have found that the best way is really via metadata. Metadata associated with each brick can mark it with key information: author, lifecycle stage, business purpose, production-ready flag, technical vs. business flag, and more. For composition platforms that are able to run in a production environment – because not all can – production metrics can be collected and displayed directly on the bricks, such as which projects are using this brick, whether the brick generates errors, or on which device the brick is running. A user developing in the platform can then effortlessly search and filter by these dimensions to find exactly the bricks they need.
Documenting what you build
Beyond metadata, each brick also needs to be accompanied by documentation of the behavior of the brick, since you don’t want to waste your time getting into the code of each brick to understand what it does. (Documentation becomes necessary in the later pillars of the composition platform).
Protecting your bricks
And finally, there must be a robust permissioning system and change log in place. This so that each brick has an owner who is responsible for its smooth operation and maintenance. With proper permissioning, an enterprise that has created its own proprietary bricks can set permissions to secure their bricks from other enterprises using the composition platform.
How not to end up like Joe
The issues our unfortunate business analyst Joe faces could have been avoided if his marketplace used metadata tagging to organize its catalog. A simple “usage” tag on each brick with a value of either “UI” or “logic” would have instantly shown him which bricks to ignore and which ones he will probably find useful. If the marketplace provided searchable documentation for bricks, Joe would have found exactly the login screen he needed. And if the marketplace had proper permissioning on each brick, his colleagues would not have been able to accidentally break his application.