Last month, I started summarizing all my API-related posts, workshops, and webinars into extended and structured reading. That is usually a part of the Essays section, where you can find my recent Replacing Legacy series.
Reflecting on my past materials about API, I realized they were disconnected and lacked a logical narrative. However, I am proud to share that I am starting anew, from simple concepts to in-depth reviews of various Interface Definition Languages, showing significant improvement in my approach.
The new chapter, "Analysis," focuses on business analysis and aspects of requirements engineering. That was tough to write and edit, cutting pieces that did not fit and made text difficult to comprehend. Hopefully, I will get a satisfactory result.
The following case study focuses on dependency management, omitting other details that are irrelevant to the topic or might be sensitive to share publicly.
I do not necessarily speak on my behalf. Let's assume some Product Owner (The PO) appeared in such a situation and acted a certain way to resolve the dependencies.
This is what the team topology looks like, approximately. And that impacted how dependencies are distributed.
Three organizations are involved, each with their own development teams and management. It is obvious that each side pursues its own goals in accordance with contractual obligations.
Recently, LinkedIn asked me to share my insights to be eligible for the "Top Voice" badge. I realized that I have something to share with my followers in a more extended way than typical (ChatGPT-generated) answers to those top-voice questions.
As usual, let's start with the definition, which is rather made on my own. When you need someone to do something so you can do your work, that is a dependency. Postponing the dependency means a delay in delivering your work and the expected outcome, which causes financial losses.
Your team/service can have one or several dependencies and be a dependency for someone else. Sometimes it can be both. And dependencies might be temporary when you need something to be done once or permanent when you continuously need something to operate.
There can be external dependencies, meaning that you are waiting for something to be done outside your organization. Or that will be done inside your organization, which is an internal dependency.
We can distinguish cross-team, cross-stream, and cross-department dependencies, each with its own peculiarities.
In my world, dependency means an API or a software library. In your world, that may be anything else, like a vehicle part or a plumber to fix a pipeline leak.
Although this resource might be for local business analysts in Warsaw, I am adding a product management and product ownership perspective.
So, if you happen to live in Warsaw, we would be glad to have you join one of our events. If not, enjoy this newsletter.
Also, I decided to postpone the idea of my newsletter. This commitment seems too heavy at the moment. I enjoy my current writing schedule of about two articles a month. I don't want it to become a job instead of joy.
Looking at the title, this book is not about product management or business analysis...
Yes, you are right. This book is about constructing teams and establishing their interactions. It is not about my day-to-day work, but it is an area of my concern. I tend to read general books about management more and more. So we will discuss more such books in the future.
How did you find out about "Team Topologies"?
I heard about it during the Platform Engineering fundamentals course brought by Tyk (I have a fancy certificate, by the way). There were a lot of references to that book, so I decided to add it to my reading list.
It is funny, but "Team Topology" references many other sources but combines them into a solid idea.
The book basically addresses the most common problem, probably on the humanity level.
What kind of problem do you mean? We have plenty of those.
I am proud to present the second edition of the monthly newsletter made by BArszawa - the Business Analysis community in Warsaw. In one of the previous posts, I explained what this community is and my role in it.
I act as an editor, combining some materials gathered by the Community OrgTeam, writing a foreword, and publishing on different media platforms.
Hoping you enjoy that post and find it helpful. Please feel free to share it with your friends and colleagues, support us, and visit us if you appear to be in Warsaw, Poland.
SWEBOK Guide, by its nature, is similar to other Bodies of Knowledge (PMBOK, BABOK, etc.) and stands for the Guide to the Software Engineering Body of Knowledge. It is not a standard but a guide that defines the scope of software engineering as a discipline (that is important to address). It outlines Knowledge Areas described in terms of its component processes, practices, inputs, outputs, tools, and techniques. Those areas are representations of the discipline at a particular moment.
Of course, Software engineering can't ignore such a massive topic as requirements. So it contains a dedicated chapter, or, in SWEBOK terms, knowledge area (KA) "Software Requirements".
I started learning about industry standards and Bodies of Knowledge a few years ago. So I went through SWEBOK Guide v3, published in 2014, to review existing KAs focusing on the "Software Requirements."
The 4th version is in the public review and will replace v3 soon. This article compares the Software Requirements chapter, my domain of interest, between newer and current versions. And there is what to compare. But let's go back to v3.
And there is not much there. The KA heavily relies on an older edition (2nd) of the "Software Requirements" by Karl Wiegers and just a few other well-known sources. And the chapter itself is about 18 pages long. The Guide should not provide extensive information about a particular topic but should give an overview and further references to study.
However, the provided information is insufficient to give an overview of such an essential piece of software engineering. Moreover, it struggles to offer a structured categorization of requirements types and a comprehensive overview of requirements practices.
I am not criticizing; I am expressing my feeling that not enough attention was given to that part of SWEBOK. And written in 2014, it quickly became outdated.
I read it for the first time in 2020, and RUP (Rational Unified Process) has already been dead for a while. I barely heard about practicing RUP in 2014 because Agile methodologies were on the hype train then (and claimed to be dead soon, too). A newer generation of IT folks has no idea what it is.
I could not recommend SWEBOK Guide v3 to start your journey to the requirements engineer or business analysis. Even at the moment of 2014, there were better sources and materials. This KA looks unarticulated compared to the further KAs.
The good news is that v4 has done everything right!
In 2024, I started revisiting the standards BOKs, researching some topics for future articles. For the sake of curiosity, I have looked into a draft version of SWEBOK Guide v4 (2024 Jan 16th Public Review Version). And I am surprised in a good way. The "Software Requirements" KA has been completely rewritten and extended.
I am not going to dive deep into reviewing each point. You can easily read the document and make your conclusion. And we need to consider that it is still not a final version, and some changes are expected. However, I don't expect much will change: IEEE (Institute of Electrical and Electronics Engineers) folks and KA editors have done a great job.
For those who are not Medium fans, I've packed the Replacing Legacy series into the long read available on my blog.
There are some slight differences from the original: some passages have been edited, and others have been removed. Text is now more straightforward, but there are still a lot of places for improvement.
Now everything is in one place. I hope you enjoy reading.
And a few more updates:
-> I keep experimenting with formats and media platforms. Now, I will no longer publish unique content on one platform, like I did with the above-mentioned series on Medium.
I will simultaneously post on Medium and my blog. On LinkedIn, I publish a link to the blog with a short summary. So there will be a choice of where to read. And I will not spend time again migrating content from one place to another.
I am unsure about maintaining LinkedIn Articles, as last year's experience was not the best. The traction was minimal compared to a usual post.
I wanted to conclude the Replacing Legacy series with something less practical and more philosophical. Here are my thoughts on why we are at this point of rapid and sometimes senseless replacement or modernization. And what does the future bring us in the face of AI?
I did some research for the AI part and felt a lack of knowledge to read scientific papers. Like one about the CARGO algorithm, I mentioned in the article. I really tried, but I cannot fully understand the details. That is a considerable gap to be addressed.
I recently bought a course about Product Management in AI, but I am unsure how technical it is. I still don't know how to embed that course into my schedule.
