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.
With Convecton, BeSafe can rely on a rich specification environment that is tailored specifically to the Fachlichkeit of its insurance business, coping with its essential complexity. Convecton allows to disentangle the Fachlichkeit from the source code and bring it to life. Paula can capture her knowledge in well-formed, unambiguous insurance product specifications, using notations familiar to her: text, math, tables, graphics. Her input is instantly checked for consistency and can be validated against BeSafe’s business constraints. It can eventually be transformed into software that runs on the execution platforms maintained by Knut and his teammates.
Paula can better understand her product specifications. This allows her to build trust in and take responsibility for their correctness and their business impact. She can feel confident when handling 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, Paula and her team can simulate and play with them to explore their behavior. They don’t have to “imagine” how a product might work by reading a piece of paper.
Knut is relieved from having to understand all the product details. Once he and his team wrote the code generators for the specification language, new products can be transformed into code that runs on their platform on the press of a button. Because the tests written by Paula and her colleagues also run on the “real” execution stack, he can trust the generators to be correct. Importantly, because the implementation is generated, it is relatively easy to retarget it to another platform. This accomplishes independence of the technical software architecture from the Fachlichkeit, a goal he and his guys have had for a long time.
The bottlenecks of 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 is streamlined.
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.
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.
Convecton specifications employ familiar notations, such as tables, formulas, text or diagrams, enabling 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 execution 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 execution platform.
Convecton specifications are aligned precisely with the Fachlichkeit of your company or department as it uses your established domain abstractions and notations. This makes them accessible to domain professionals and other stakeholders such as quality assurance or government agencies. They are precise and unambiguous, so all stakeholders can explore, validate, and test them to build trust in their correctness and business impact.
Convecton streamlines the entire lifecycle of your Fachlichkeit, from exploratory prototypes all the way to the development, evolution, and management of large bodies of specifications. Convecton leads to a system architecture that clearly separates business from the technical concerns of a reliable execution environment; this decouples the two concerns and increases agility, both in IT and business.
Convecton is a product of itemis.