When working in an enterprise environment with several (or a lot) of applications developed in different languages, technologies or even on different platforms, but still tightly connected to each other, changing one minor thing in one application can have huge impact on the chain. That's why technical alignments exist. But in order for them to exist, you must first have a proper structure within your organization to support it.
Assumptions
Before we start, let's be clear which environment we're talking about here. We are talking about a connected set of web services, business, sales and analytics management software usually combined with one or more front-end facing applications (parts of the system which your consumers will use).
Target audience are team leaders, solution designers or development team members interested in how an alignment process works and who are the participants.
Technical alignments
Technical alignment is a process of making sure that a change in one application will not result in problems or that it doesn't crash some other application in the chain. The more applications there are in the chain, the greater the possibility of a change having an impact on the chain is. Of course, if you have a lot connected applications, teams working on individual applications, no matter how skilled they are in their area, can and will overlook an impact of a change in some other application. If that happens and the technical alignment was not done, the "blame game" is the last thing you want to do because none of the teams technically failed - the process itself was wrong.
A good technical alignment will have one or more meeting sessions between Technical Leaders from each team and a Solution Designer. The result will be an architectural solution for a change which will have a minimum impact on involved applications (in order to reduce development costs) and at the same time be the best possible technical solution (in order to bring value to the system). Sometimes multiple solutions will be possible with different balance between development costs and actual value (or quality) of a solution, so decisions in which solution the company will invest should be coordinated by a business oriented staff - a Change Manager. No matter how many solutions there are after technical alignments are completed, each solution and its implementation method in each affected application should be completely clear to all involved teams. When the business decision is made, the teams should be ready to start implementing what they've agreed on.
Technical Leaders
Flat team structures are bad. In theory, giving your team freedom to decide who will work on which part of application brings more satisfaction to the people involved in development and can work in smaller isolated teams. Having a flat team structure in an enterprise environment, however, only brings chaos and late delivery.
In order to avoid that, a Technical Leader should exist in each team. Technical Leader's responsibility is to have enough knowledge of the application he/she is responsible for to either assess the impact of the change on their own application or know which team member has the most knowledge about that particular part of the application where the change has the most impact. During the alignment process, Technical Leaders are communicating with Technical Leaders from other teams in order to properly implement a change and avoid chain instability or application incompatibility.
Since in a typical enterprise environment you will most likely have applications written in completely different technologies and underlying architectural principles, having a bunch of Technical Leaders throw ideas at each other will usually not result in a constructive and productive conversation. In order to have a productive alignment session with a reasonable amount of time spent, an overseer is needed who can understand each viewpoint from a technical perspective and filter out bad or nonconstructive ideas. That brings us to the role of a Solution Designer.
Solution designers
Apart from the team and a team leader, you'll need a dedicated person who will be in charge of overseeing the architecture of the whole chain (or a part of it which can be logically separated from the rest) and coordinating changes. They are usually called Solution Designers or Architects. Solution Designers must be technical staff with both extensive development experience and great soft skills.
If you have a manager with little to none understanding of the underlying technology behind each application on this position, you will have a lot of well organized but sadly nonconstructive meetings where each team propose their own "best solution" and brainstorm ideas forever. On the other hand, having highly technically skilled person without soft skills will either result in the same chaos as with a manager (if your Solution Designer is a "soft" decision maker) or result in a risk of making wrong architectural decisions in multiple applications because your Solution Designer's "no compromise" decision making approach is a Single Point Of Failure in your application chain. Both of these bad types of Solution Designers can and will cost your company a decent amount of time and money: lost hours on nonconstructive meetings which could have been used to bring value to the project, bad architectural decisions which produce more problems than they resolve, necessity for system overhaul and refactoring in multiple applications,.. you name it.
So what does a good Solution Designer do? A good Solution Designer will organize meetings with Technical Leaders, understand the change from the technical perspective, analyze possible architectural solutions for the change by using his/her own technical knowledge and be open for considering solutions proposed by Technical Leads. A good Solution Designer must be able to ask the most challenging technical questions and continue to drive the communication with Technical Leads until even the smallest bit of unclarity is removed. "Is-this-part-clear?" should be the informal nickname of your Solution Designer. Ultimately, a Solution Designer should be an effective decision maker able to push the architectural decisions to all involved teams.
Change Managers
There are three main dimensions of a technical solution: development cost, technical value and time needed to implement the solution across the chain (or how fast the change will be seen by end-users).
I was going to write a bit about each of these three dimensions, but this article is primarily intended for technical staff (ex. team leaders, solution designers and developers). So, let's just say that a Change Manager takes these three dimensions into account when making the decision on which of the proposed solutions will be accepted.
Conclusion
Now that we have the whole personnel structure ready, the communication and decision making should be more clear and efficient when implementing a change in an enterprise environment. The only thing we need to do now is to prepare and start the technical alignment process. That's something which will be posted in one of the articles in the future.
Top comments (0)