This post is intended to go deep in the topics discussed on this post: https://techblog.fexcofts.com/2018/06/07/software-delivery-analytics-2/
The first step to build a any kind of software, consist in define what the system should do. Depending on the methodology that company have adopted, the approach to accomplish this may be different, but the goal is the same: Determine what we can expect from the system.
The expectations of the system often are stored and shared on several ways, which could be:
- Cards (like Jira Cards)
- One or more Word documents that explains these expectations
To simplify, let’s just refer all of these ways as documents. And so far, all of this documents suffer from the same problems:
- The information could be too ambiguous
- The information is tedious to read
- Depending on the way that the are organized, getting the last version of a documents is tricky
In order to the AIOps platform to be effective, it needs to understand this expectations, so it can accurately measure through functional if the system is working properly.
One of the most time consuming stages of the system that we face on understanding what are the systems expectation, comes from the way that these expectation are expressed.
Ambiguity in form in which the expectations are expressed
If you’re a Software Engineer, I’m sure that at some point of your career you have faced (or you will be) a situation, in which you carefully read a document and still you aren’t sure what the Business Owner (BO) wants from it.
Often, this happens because the document is written in an ambiguously way, and therefore, you start to feel insecure that what you’re going to deliver will meet the BO expectations. When this happen, often you will simply ask clarifications to the BO, then write down the clarifications into the document, and repeat the process until you feel confident enough to deliver something.
Lack of understanding the domain language or the absent of it
Sometimes, you can read a document that is only clear to someone that understand the BO’s technical language. Its good if the software engineer understand the BO technical language, but of course, as you may guess, that’s not always the case, and if you don’t understand BO technical language, communicating with him will be hard.
A common solution for this, is define a set of terms that will make the communication easier. Sometimes, this definitions are made in a organic way, other times, in more explicit way. Whatever is the case, we call this set of terms a Domain Language (DL), and often until you don’t have it defined, understand the BO expectations will be cumbersome.
Unaccessible business owner
There is cases, in which the business owner is a very busy person, there, its availability is limited. If you cannot have a constant communication with the BO, it will be arduous to define a DL and obviously, it will be time consuming for a software engineer to clarify any question that could arise from reading.
This situation often force the software engineers to makes assumptions about what could be the answer of its questions, until they get an answer from the BO, and when the assumption is wrong it could mean a lot of wasted time.
Submitting expectations to the platform
So… How can we improve the process of establishing what the system should do? How can our platform help software engineers to understand faster the expectations of the business owner?
For us, one way to achieve this, is by helping the BO to express himself in a more concise way. What if we provide to the business a Domain Specific Language so he can express his expectations? Sound a little bit crazy, but this approach have a lot of advantages.
With the use of a Domains Specific Language (DSL), a BO can put their expectations in a clear way, therefore, the necessity of further clarifications will be reduced. If it happens that we need a clarification, the conversation with the BO will be within the DSL terms.
The expectations could be easily translated to business rules, requirements, business entities, etc. And, with all this in place, it should be easy to create tests that ensures that the expectations are being met.
Which means, that we would have gained the ability to measure the progress of the development from day one. Also, it will enable us to automatically create cards that will inform software engineers what are requirements that they need to accomplish.
If the DSL is smart enough, we could infer some technical details that the project needs and create project skeletons based on that. Isn’t that really cool?
Keeping track of the development process
As I said before, providing a DSL help us to create automatically Jira Cards. Therefore we don’t need to wait to someone to create a card to be able to start working.
If we create our Jira Card though the AIOps platform, it means that is also have visibility on them, so it should the monitor the overall progress of project though the AIOps platform.
Another cool thing that we can do, is monitor the performance of the developments once they are deployed, therefore in the future we could even forecast the system performance if larger amounts of data are provided.
Monitoring the performance of a project right from the start, have another advantage rather than obvious, and that is to help us to shape the mentality of the software engineers involved in the development process to think on monitorization right from the beginning of the project.
Using the IAOps platform as the entry point for project management, provide a huge deal of advantages. Not only in terms of development, monitoring, and automation, but also on project planning. The question is: how should be this DSL? That a something for a later post.