Collaborate
Software development is a team sport requiring close collaboration between people coming from very different backgrounds and subcultures.
Visualize
In order to bridge the communication gap between domain experts and software experts, it is super helpful to leverage visualization at all levels.
Implement
Teamwork cannot end with an handover of models. Executable software is the only relevant form in which our success ultimately exists and is maintained.
Domain-driven design (DDD) is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of core business concepts. Its premise are: 1) Place the project’s primary focus on the core domain 2) Base complex designs on a model 3) Initiate a creative collaboration between technical and domain experts to iteratively cut ever closer to the conceptual heart of the problem. The premise is simple, but pulling it off in the messy real world is hard. It calls for new skills and discipline, and a systematic approach. Domain-driven design is not a technology or a methodology. DDD provides a structure of practices and terminology for making design decisions that focus and accelerate software projects dealing with complicated domains.
Check out DDD Fundamentals training Get in touch
Storystorming is a toolbox and mashup of existing methods to collaboratively explore user journeys, work procedures and business processes and refine them into working software models. Storystorming facilitates many opportunities for collaboration between business and technology experts, helps them to visually connect the dots and discover what your organisation needs to be successful. By visually mapping known methods such as Domain Storytelling, User Story Mapping and Impact Mapping to a small set of reusable building blocks and colors inspired by EventStorming, these methods become more accessible to busy organizations, but can also be easily linked with each other.
Learn more Check out Storystorming training Get in touch
Business process modeling is about visualizing activity flows, so that they may be analyzed, improved, and ultimately automated. It can be performed by business analysts, who provide expertise in a modeling discipline, by subject matter experts, who have specialized knowledge of the processes being modeled or directly by software developers, but in the best case by a team comprising all of them. Often, super lightweight process modeling methods like we find them in Storystorming (see above) will be good enough as a prep to “go and code”. But for logistically challenging endavours or if you use a workflow engine (like e.g. Camunda) a solid knowledge of the powerful ISO standard BPMN can do the “trick” for you and if you combine it with lightweight workshop methods to tap into the expert’s knowledge - even better.
Check out Collaborative BPMN training Get in touch
A domain-specific language (DSL) is a small computer language specialized to a particular problem or application domain. This is in contrast to a general-purpose programming language, which is broadly applicable across domains. There are a wide variety of so called “DSLs”, ranging from widely used languages for common domains, such as HTML for web pages, down to languages used by only one or a few pieces of software, such as MUSH soft code. DSLs can be further subdivided by the kind of language, and include domain-specific markup languages, domain-specific modeling languages (more generally, specification languages), and domain-specific programming languages. We have some solid experience in designing such languages.
Learn more Get in touch
FactscriptFactscript is a process scripting language designed to make developers happier. It is implemented in Kotlin for the Java software platform and one of the above mentioned “internal” domain specific languages: a language specialized to express non-atomic, multi-step business or software processes directly in code. Factscripts do not only define the process flow in a type-safe manner, but also include all data aspects needed to control the flow. Therefore such scripts can automatically be translated to BPMN and are then directly executable and deployable to a workflow engine (Camunda). The language was designed and implemented by Martin Schimak, plexiti, in an open source project collaboration with PHACTUM and the Institute for Information Business (Vienna University of Economics and Business).
Learn more Get in touch
“Fact-Driven Architecture” is our research topic and a provisional term for a combination of patterns rooted in Event-Driven Architecture, Greg Young’s Event Sourcing, Mark Burgess’ Promise Theory and Pat Helland’s seminal paper about Life Beyond Distributed Transactions. In a fact-driven architecture autonomous agents promise each other to work towards specified outcomes in case they observe certain messages. They interact with each other by means of “facts” only, meaning that all messages exchanged between agents are persisted before they are transmitted and persisted after they are observed and processed into new facts. All messaging and promising is based on the four sentence types rooted in the human language: commands, questions, statements and exclamations/events.
Learn more Get in touch
