3Ten reasons for Ampersand
The purpose of Ampersand is to help business architects deliver. Ampersand lets you design information systems that actually do what users want. It allows you to offer information systems to the business that comply provably to the rules by which they conduct their business. And it lets you work fast. How cool is that!
How does it work?
- Communicate with the business in their own language. Define a domain language1 to consolidate agreement of terms among stakeholders. Ampersand formalizes part of the business language that is used in the information system. Ampersand gives you a (documented) ontology.
- Generate a real and working prototype of your information system at the push of a button. Use this prototype for walking through user stories, acceptance testing, requirements elicitations, to name just some of its uses.
- Express your design in business rules to let anyone concerned convince herself that the system supports the right rules.
- Define your information system in a declarative language. Why specify all the steps towards your goal when you can specify that goal directly?
- Enjoy the benefits of strong and static typing. Several scientific studies2,3 show significant effects of strong and static typing on the total cost of ownership of your design. Besides, it enables Ampersand to generate efficient code.
- Use relation algebra4 to align the IT-system to the business, by exploiting its natural language interpretation alongside its technical interpretation as working software. Your claim that business stakeholders understand (solely in natural language) what the computer does (in software) can't be made more convincingly.
- Develop in small increments. Add constraints, user-interfaces, relations, and other design elements one at a time. Generate a prototype at any intermediate stage, to visualize your design long before it is finished.
- Design subsystems5 in isolation, due to conceptual independence. Ampersand lets you combine subsystems into larger systems, automating the burden of combining them. Reuse design patterns to assemble systems, rather than re-invent from scratch.
- Document your design embedded in the specification, so you always have up-to-date documentation which is consistent with your design.
- Specify with mathematical rigor, without being a mathematician. Ampersand gives you correctness and consistency in return, with mathematical provability to back it up.
1. A domain language is the business language upon which stakeholders can agree. This is usually a small subset of the actual business language, because you only use the part that is relevant in your information system. ↩
2. Hanenberg, S., Kleinschmager, S., Robbes, R., Tanter, E., Stefik, A., 2014. An empirical study on the impact of static typing on software maintainability. Empirical Software Engineering 19 (5), 1335–1382. ↩
3. Petersen, P., Hanenberg, S., Robbes, R., 2014. An empirical comparison of static and dynamic type systems on api usage in the presence of an ide: Java vs. groovy with eclipse. In: Proceedings of the 22Nd International Conference on Program Comprehension. ICPC 2014. ACM, New York, NY, USA, pp. 212–222. ↩
4. Schmidt, G., Hattensperger, C., Winter, M., 1997. Heterogeneous relation algebra. In: Brink, C., Kahl, W., Schmidt, G. (Eds.), Relational Methods in Computer Science. Advances in Computing. Springer-Verlag, Wien, New York, pp. 39–53, iSBN 3-211-82971-7. ↩
5. Think of subsystems as in a car: it consists of a fuel-subsystem, a climate-subsystem, a comfort-subsystem, an electrical subsystem, etcetera. Think of subsystems as in a human body: it consists of a circulatory system, a muscle system, a nervous system, etcetera. ↩