Digital Transformation Enablement
Digital Transformation, a popular concept, which is embraced by many organizations, on last decade. Different organizations adapt different models according to their companies’ needs, technical capacities, and future organizational strategies. Hundreds of highly skilled technical people work thousands of hours on different layers of systems to discover how the next architecture will be. Hundreds of pages of blueprints, charts, graphs, diagrams, guides prepared.
Meetings/Questions/Answers follow each other consequently. Tremendous amount of money, workforce spent on “the next big thing”. At the end of all those, “the new architecture” shows up. Faster, smarter, better than ever before in every aspect.
Applications supposed to work much better on this very new environment. Technical teams are waiting for Business Teams to adapt their applications on masses. An announcement made to the whole company, which says everything is ready for business applications to adapt.
And then first business team shows up. They want to refactor their application by using the new architecture! (What a joy!).
Framework teams share their guidelines about the new architecture and how to make the implementation and they are very detailed (Seriously).
Just a couple of days after initiation to refactor, the business team pings technical teams with some questions, which are not in the guidelines. Since those questions are specific to their applications, there is no way the guidelines have the answers.
Since technical team is very well experienced, they give answers to those questions immediately and the business team continue to do their work.
And then second business team joins to the club. They started to refactor their application by using the new architecture and they also have some questions. So, they ping technical teams as well. Besides, the first team have some more complicated questions than before too and they send an email for a meeting to discuss those (and they ask for some favours, new features which are needed as well). Technical teams, say “Oh ok, we can handle that!”.
At the end of the month, 15 different business teams have been started to implement their applications on the new platform and all of them have several questions (some of the answers are already on documents, but nobody reads them), asking for new features, requirements, and some bugs, which might come from the framework or application’s code, who knows!
Can technical teams handle all of those?
Digital Transformation teams always work on, “How the next architecture should be?” more than “How business teams could handle new architecture?” which is quite expected behaviour for technical teams.
However, even the guidelines are clear and perfect, business teams’ technical capabilities might not be well enough to handle this transition, or the new architecture might not cover all needs of business applications. For technical teams, there might be some necessity to implement, new requirements and capability improvement of the new platform even after the major announcement.
So, there is a need to manage new requirements for the architecture, while determining if those issues belong to the new platform or business team’s issue and besides keep all current documents/guidelines updated with new features and announcements. We all know that, while improving the platform’s technical capabilities, it is not much possible to return business team’s questions/requirements and some of those issues might not be even a bug.
Because of this, in digital transformation process, there is a need for a separate enabler team, that confronts all emails/meetings/issues, which are received from Business Teams, no matter if those issues are platform related or application related. This team must be formed by the members, who are coming from different backgrounds that are able to understand the issue and guide business teams accordingly, to solve their problems.
This team will enable the change for business teams to implement their applications on new platform by driving them to solution. Since business teams, can be able to come for different issues for different layers of the platform, this team’s members must have the knowledge about every layer of the platform. For example, a typical modern platform consists of many layers. Such as; devops, security, data, backend, web components so on and so forth. So, every member of this team must be specialized at least one layer of the platform. So, when a business team comes up with a question, at least one member of this new team, can be able to answer the question, without taking time of the technical team. So, consider this new team as a semipermeable wall.
Semipermeable, because if the root-cause of the issue is platform related, then this team’s member will file a bug and inform the related technical team about the bug and ask them to fix this issue as soon as possible.
If it is not a platform related bug, then this team will guide business team to how to fix the issue on their application’s code and update the related documents by giving more information or general announcements if it is a very common mistake.
The very same process can also be applied for all platform requirements, which are asked by business teams. If there is a need for a new capability, which improves the platform, this Semipermeable team will get this requirement from business teams and ask technical team to implement the feature as soon as possible.
Sometime later, these bugs/requirements will be so many that, there might be a necessity to manage them all on a daily/weekly basis. So, this team, will check if those features or fixes implemented on expected date by generating a report by using the tool, which bugs/requirements are managed.
With this new team, technical teams will not need to spend their time and effort for business team’s issues or questions, which are not platform related and all issues/requirements of the platform can be managed by one team. Since they will be the team, which faces with so many issues/questions, experience and capability of this team will increase by the time and response time will be decreased. This team will be more capable than ordinary operational team on legacy platforms. They will drive the implementation of business teams.
They will enable the change.
In one of our clients, we have established this team, as mentioned above, and placed it as a wall in front of technical teams, and made an announcement to the business teams to get in touch with that front team if there is an issue or question regarding to platform. The front will be the team that guides business teams regarding the solutions. The main aim of this notification is, to place the team as a single point of contact to business teams. In the first days, the business teams, made a resistance to communicate with this team (because they already know someone, who is capable to solve the issue inside technical teams). However, technical teams redirect those emails to this front team, to force them to communicate with the front team.
Since this front team already has experienced members on different layers of the platform, it was quite easy for them to manage those issues. And as mentioned above, most of the questions are like each other. So, this front team started to send E-Mails to business teams for tips and recommendations to not do the same mistakes. Besides, since they are the team, which communicates with business teams directly, they started to gain experience on how the guidelines become better. So, they can make recommendations to the technical teams for their guidelines. In addition, in case of platform related issues, they inform the technical team immediately and follow those issues/requirements daily/weekly. So, technical teams only face those subjects, which are related to them.
The main contribution of this team is to enable the platform change across the company and accelerate adapting process of the business teams. Platform adaptation process will speed up, because there will be a specific team between technical and business teams, which increases its knowledge and know-how on different layers of the platform day by day, so they guide business teams faster. Since business teams can be able to get support faster, they will start to communicate with this team, rather than technical teams. By this approach, technical teams can have time to focus on how to improve the platform in architectural way, without distracting with questions/answers from different business teams and also bug/requirement management process will be handled with different team, which also consumes time and effort.
So, at the end of the day, we have a team, which helps and guides business teams on how to adopt the new platform by providing guidelines, answering their questions, and providing fast and early feedback. In our case, after forming this team and with their guidance, the adaptation rate of the new platform has increased dramatically.
Business teams are happy to have answers quickly and their willingness to do more on the new platform is also increasing every day. Some business teams are so loved the new platform that, they asked to contribute on the platform development even. With increasing adaptation rate, the platform improves, and the digital transformation process becomes successful and overall, the platform becomes more beneficial to the company. And besides, since high skilled technical teams can focus on their work more, they are able to add more features to the infrastructure side, which also improves the quality and reliability of the platform in the meantime.
Omer Coskun, Consultant @TeamDefineX
