“In commerce, time to market (TTM) is the length of time it takes from a product being conceived until its being available for sale. ” – Wikipedia
Knowing this concept, beware that time and assertiveness are decision makers for either huge enterprises or small startups who enters in a competitive rush. Digital transformation is the key that companies are using to improve their business by building a better customer experience and reducing their time to market.
Executives who decide to take a step (or more steps) into digital transformation rely mainly on tech teams. If the tech team succeed, the whole company succeed.
That’s where software architects come into scene!
Microservices, Devops, Cloud-native and all related buzzwords are accelerators on software development and are boosters to reduce the time required to release code.
Even when these practices are aligned with agile methodologies, some bureaucracies are involved in-between teams and lots of steps are needed when a change request is defined by the business area: use case documents, business rules documents, workflow designs, e-mails, meetings, validations, sprint reviews, planning, or whatever processes used, should happen before the need gets to the hands of a developer.
All these processes seek assertion on business knowledge transfer through teams. And they also consume time.
What can we do as software architects in order to reduce the TTM and help our companies succeed?
In 2019 we shall see even more decentralized architectures and, as mentioned by Martin Fowler, “organized around Business Capabilities”. You should not only break your monoliths into smaller peace, but you should also remove workflows and business rules from your application codes.
Business assets are intuitive for Business Experts. DMN, BPMN, CMMN are specifications which allow developers or business experts to draw rules using tables and process flows using drag and drop tools to create assets. And these assets that are saved as code. Versioned. Integrated. Promoted. (Can you see all the advantages already?)
Setup an authoring environment and delegate the creation of business assets to the owners of business knowledge.
Start by extracting simple business process and/or business rules from within application code.
After authoring processes and rules, they shaw be packaged (under the covers) with maven, storing all the Knowledge into a Java Archive. Hence, the origin of the kjar package name.
Once business assets are packaged, use a cloud-native scalable engine to execute and allow interacting with it.
A suggestion? [Code, copy, learn from, alter, or share, use] open source technologies. Kie Server is the engine delivered within jBPM project. Allow integration of any service and application via REST or JMS in order to interact with business assets. It can also be embedded and run using spring boot servers.
Use cloud-native and scalable process and rule engine to allow decoupling business assets.
By fully decoupling business assets and delegating its creation to Business Experts, you will allow faster changes on business requirements, parallel development from the business assets and additional services, and allow a (beautiful) fully independent deployment process using CI/CD pipelines. Logic can fly from Business Experts hands, to the cloud 🙂
Welcome to 2019, buddies.
Keep Kalm 