Are we going to be disrupted?
I just finished the third revision of the specification. But I'm sure it will take another two month of annoying ping-pong with the IT.
Once again the spec was crap. Another 3 month wasted …
BeSafe is a medium-size insurance company. Their competitive edge results from defining innovative, tailored and profitable insurance products.
Paula is a product designer at BeSafe. She and her teammates are responsible for defining the data structures, calculations and rules that make up an insurance product in terms of fees, payouts, deadlines and constraints. They are also responsible for assessing the profitability and regulatory compliance of the products.
Knut is a software developer at BeSafe. He and his teammates write the software that runs the products specified by Paula’s team in BeSafe’s data center, ensuring availability, scalability and security.
Because Paula is responsible for the products’ consistency and profitability, she uses Excel, and sometimes Matlab to model and test key aspects of each product. Once she is confident about a product, Paula uses Word to write the final product specification, relying on natural language plus a couple of tables and the occasional mathematical formula or diagram.
Paula then hands the specification over to Knut and his teammates so it can be realized in software. While the development team has built considerable expertise regarding insurance products over the years, it is still a challenge for them to implement a new product correctly: they struggle to understand the details. To him, it feels like they are “debugging” the specification and they are expected to become an insurance expert.
While the software development is ongoing, Paula supports Knut’s team with the validation of the software against her specification. This is a mostly manual and lengthy process where she compares the running software against the document. In the case of inconsistencies, Knut digs into code and tries to follow. Which is hard for her, because she cannot recognize the specification in the details of the code. Paula feels like she is expected to be a deputy software engineer.
The demand for new products increases rapidly as a consequence of shortening times to market and increased product differentiation due to BeSafe’s expansion into new markets. Paula feels held back by the long feedback cycles and the late go-live of her products.
She understands that one reason is that the product specification inevitably contains omissions and inconsistencies. She has an intuition that a higher degree of formality, like in her Excel spreadsheets, would help. Currently, the overall feasibility of an innovative product can only be checked by involving the developers. They, however, are mainly driven by technical concerns. And she feels like Knut has limited interest in this part of his job, she suspects he doesn’t want to become an insurance expert.
What Paula really wants is an integrated product modeling tool, where she can unambiguously describe the products, explore the behaviors and their impact, and build trust through tests: a bit of a cross between Word, Excel and Matlab. This way, she would be able to take real responsibility for the product, even before the development team gets involved.
As Paula suspected, Knut is not happy with the process either. He feels responsible for providing a reliable software stack that runs products and makes them available to customers and agents through web applications. In today’s world, this alone is a serious challenge!
Instead, he spends a lot of time understanding, clarifying, debugging and ultimately fixing product specifications. He feels like he’s doing Paula’s job. This distracts him from his core responsibilities and also leads to considerable friction between the two teams – a classical blame game.
Knut also has architectural concerns. Once the specification is molded into software, it is not maintained any longer. The code becomes the truth. However, this is a problem regarding the future evolution because Paula cannot effectively read or even adapt the code as products evolve. Porting to another technology stack is also effectively impossible, no matter how well the code is structured. This limits his team’s ability in keeping pace with technological innovations and adopting new platforms.
He would love it if Paula were empowered to take real responsibility for her specifications in the sense that products already “work” when they show up on his desk. And he would love to see test cases to run against his implementation. He imagines a clean, technology-independent but still executable “implementation” of the insurance products, provided directly by Paula.
BeSafe’s fundamental problem – as experienced by Paula and Knut -- is a lack of structure and formality in their product specifications. For Paula, this problem expresses itself in the limited ability to validate, explore, test, and thus, trust her specifications. For Knut the problem is the unreliable basis on which to build the software implementation. Both have the problem that specification and code diverge over time.
BeSafe’s management recognizes the problem as well: the time from product idea to implementation is too long, and requires too much back and forth. They ultimately perceive it as a major risk regarding their business agility and regulatory compliance. Management is convinced that they will not make their growth targets without removing this bottleneck.
Convecton empowers business professionals to precisely and efficiently capture their Fachlichkeit, ensure its correctness, and evolve it rapidly.
Convecton enables IT professionals to focus on the technical qualities of a robust and future-proof platform for the executable business knowledge.
Familiar notations, such as tables, formulas, text or diagrams, enable domain experts to precisely express their intent. The notations are backed by an well-defined data model that enforces overall consistency. Convecton’s integrated repository and collaborative editing tools allow multiple domain experts to jointly work on a single truth.
Leveraging the integrated data model Convecton detects inconsistencies. Interactive simulation provides instant feedback about the system’s behavior. Executable tests based on scripted scenarios help to ensure the systems desired behavior in the face of evolutionary change. Custom analyses reason about the Fachlichkeit and help optimize it towards particular business goals.
Fachlichkeit captured in Convecton can be automatically converted into executable software artifacts. Custom code generators ensure a seamless integration into the target platform. A change to the Fachlichkeit makes its way into the staging environment through the click of a button; a change to the generators adapts the Fachlichkeit to the evolving platform.
I can now take responsibility for the correctness of my specifications. No more being blamed.
Yay – no more crappy specs. Now I can focus on innovating our software stack.
… because it lets them better understand their own product definitions. This allows them to build trustin and take responsibility for their correctness and their business impact. They feels confident in handing them over to the IT professionals, who, essentially, run them without any further checking. Other stakeholders can understand the products better because the specs are more precise. More importantly, because the specifications are executable, people can simulate and play with them to experience their behavior. People don’t have to “imagine” how they might behave by reading a piece of paper.
… leveraging the integrated data model Convecton detects inconsistencies. Interactive simulation provides instant feedback about thesystem’s behavior. Executable tests based on scripted scenarios help to ensure the systems desired behavior in the face of evolutionary change. Custom analyses reason about the Fachlichkeit and help optimize it towards particular business goals.
… because its introduction has removed the bottleneck: meetings and “joint debugging” are much reduced.Even better, management themselves is enabled to experiment with innovative product ideas, understanding them and their impact much better. Generally, product innovation is easier, time-to-market is reduced and the cooperation with government oversight bodies has been streamlined.
Convecton is a product of itemis.