2021-10 Journal

AppStudio organization across teams

The way AppStudio is organize is relatively to very inefficient. Trying to organize a bunch of small team — that have, for most of them, an actual product to deliver. The F2F showed that. AppStudio initial scope is relatively small and it could be handle way more efficiently by one execution team that design AppStudio based on it's need, and work on product (and with product teams) to achieve their goal. The amount of meetings and discussion added by this "cross-team" effort is enormous (and most likely tiring to a lot of folks, including me). And even like that, we have the feeling that there is not enough communication between teams (e.g., on what is the responsibilities and boundaries of each service — and assumption that we make). This also creates sources of contentions that would be not happening if AppStudio team was one execution team.

Build Service / Tekton Service

For some reason, we brought OSBS and CPaaS team in the AppStudio loop. For some reason, we sold them that AppStudio would fit their bill. But if we look at the requirements of each, they are very different. AppStudio has the smallest amount of requirements and somehow should encapsulate all the others ? As said above, it seems to me that the current vision of AppStudio is very very close to a Digital Ocean Apps made by Red Hat. This, in my opinion, has nothing to do with a lot of requirement OSBS and other have. It doesn't even tie AppStudio to KCP.

Siamak tried to clarify a bit this in Managed Tekton Service, by proposing a Tekton Service (Tekton API served by something — kcp is impl. detail here) and AppStudio, OSBS, CPaaS, RHODS, and whatever-comes-next, to build build on top. In a simple term, all those services (internal or external) would build on top of the Tekton API. Benifiting from each others at different possible levels (Tasks, …). This got "changed" again, for being confusing — which is getting me confused. What is wrong with all building on top of Tekton ? Do we feel Tekton abstraction is not at the right level ? Do we think the abstraction that will be at AppStudio Build Service level will be the right one and more importantly, will "fit them all" ? (note: if so, then why do we consider Tekton API in the picture at all, is one question we can ask ourselves). Most importantly what are the reason we absolutely want to use the exact same system for all ? If it's to be able to say "we use the same tools as what we are selling", isn't the tekton api (+ tasks, … ) level, openshift, etc., good enough already ?

Most of the time (to not say all the time), duplication is better than the wrong abstraction. I'd rather have a few things duplicated between OSBS, CPaaS, Appstudio, … to start with, gather information on what are those duplication, and do something about it, than trying to resolve all of the problems with one abstraction that has a high chance of not getting it right anyway.

It also seems the experience and "service" vision, long-term (kcp, …), is disconnected from the first(s) milestone(s) of AppStudio. What do we want to achieve for Red Hat Summit and after ? Is our goal to present something that is usable by customer even if it doesn't do anything like the long-term vision (aka not based on kcp, …) ? Or is the goal to show that KCP vision applies and work. If it's the 2nd, then, AppStudio should not only go at the KCP vision pace but also actually participating to it, working towards it and not focus on providing an AppStudio experience independently of it. KCP seems to be at a relative experimental state, and, thus, if we consider AppStudio as a capability on top of KCP, AppStudio itself should be consider in an experimental state too (and organizationally wise it would change how we do things).

Decision mechansims and "unilateral changes"

I have some relative concerns around how is AppStudio Build Service being discussed and who is talking about what, and when. Decision, and discussion should be taken with all representative as part of it (Siamak, Guillaume, …) and it feels like sometimes some decision or changes are don unilaterally. A good example of this is the recent changes Managed Tekton Service slidedeck, without any prior discussion, and without actually sharing with the rest of the stakeholders what is confusing about the current setup (note that it had been shared with all the folks and we didn't have that "it's confusing feedback"). This creates some confusion around who are the representative of the Build Service team, and the Pipeline team for example. From my point of view, anyone who is not part of the execution teams, is not a representative of those teams and it feels really weird to me that potential discussion and decision are taken by individuals that are not part of the "execution" (organizing the work, reviewing, committing to do something, …).

From my perspective (and the team perspective), I would assume (and am assuming) that anything that is not shared to the rest of the team and not written somewhere (and accepted/agreed by the stakholder of the project) is not decided yet and can be discussed, changed or discarded.

All of this causes frustration and not only for me, and it causes enough frustration for me to have to write this and get it out of my brain. I am of course available to discuss those thoughts more, either by mail or on a call with you all.