Communications of the ACM
Software Architecture Decisions: Culture Considerations
The process of developing a software architecture plan is one that will have implications for years to come. It will affect the developers at the company very closely—many of them will work to implement the idea, and each will have their own opinion, perspective, likes, and dislikes. It will affect the customers, impacting the time to market for new features, rate of defects, and overall user experience. Further, it will affect the overall forward progress of the company, determining the ease of maintaining existing infrastructure, as well as the ability to "keep up with the times" as technology moves forward. It's not hard to find examples of Web applications that have been around for 10, or even 20 years, which were once considered modern for their time, but now are today's legacy code. Architecture decisions can have effects on the company and its culture that go beyond just the soundness of the technology, and when the stakes are so high, it's important to consider these other non-technical aspects.
Receptivity
One good question to ask about any new technology choice is: will the development team be receptive to it? To answer this, it's important to consider a number of factors of receptivity, including the context of the current tech stack (if you're making a change, does it make sense?), difficulty (actual steepness of the learning curve), and external attractiveness (how this skill set will be perceived on a resume). These three factors will come into play both for retaining developers currently working at the company and for hiring new talent in the future.
First, when making a technological choice, it's important to consider that choice within the context of the company's current tech stack. If you're choosing to move away from a language or framework that is already in use, why are you choosing to make that change? Is there a clear reason why it no longer works for you, i.e., it's dated or doesn't cover your use cases? Or are you making a change just for change's sake? With any new introduction to the tech stack, you should carefully consider the impacts of your choice on your team members: is it something that developers are open to learning? Is it interesting to them? Do they respond to it with excitement, or a feeling of dread? You should also carefully consider the communication strategy around your decisions, ensuring that it is open, inclusive, persuasive, and optimistic. Effective communication can play a large role in whether your team supports the decisions you ultimately make—or whether they feel alienated by them.
The next factor, difficulty, is fairly straightforward: is the technology easy for developers to learn, or is there a steep learning curve? How good is the documentation, and how big is the community that can help answer questions and explain strange bugs? For an example in Object Relational Mapping (ORM) frameworks, consider something like Spring; there are endless resources and forums out on the Web that developers can turn to in any instance where they get stuck. In contrast, a proprietary built-in-house ORM framework may have little documentation (and if any, only internal) and only a handful of developers to help debug issues and answer questions. This, in the best case, can cause a bottleneck, and in the worst case, a complete loss of knowledge if those key developers were to leave the company.
The third factor, external attractiveness, is mainly important for hiring new talent over time. Developers in the job market generally will not be interested in a role unless the corresponding technologies are a good fit with their interests and career goals. Therefore, it's important to consider the perspective of a new hire when making technology framework choices. This is also a subjective factor and can be improved by positive communication in the job description and during the interview process. In addition to new hires, external attractiveness is also important for retaining the developers currently working at the company, because they, too, care about their personal growth and want to work with technologies that maintain their competitive value in the job market. They will not want to stay and work at a company if they fear they are being backed into a technological corner. So, if you want to keep up with your competitors in terms of team performance and talent, you'll want to keep up with them in terms of technological relevance as well.
Speed to Market
Another important factor to consider in architecture decisions is how quickly they will enable you to deliver tangible value to customers. This decision point can become a difficult balance of idealism vs pragmatism, perfect vs "good enough." At one end of the spectrum, you might be considering a completely off-the-shelf framework (commercial or open source) to address the problem you're trying to solve, but maybe it doesn't quite cover all of your edge cases. At the other end, you could pivot all the way to a custom/proprietary solution, which you can ensure will cover all of your use cases more "perfectly," but will take significant time and money to develop.
If you're faced with this dilemma around a back-end framework, it's important to factor in the additional time it will take to develop user-facing features on top of it. Good questions to ask around this are: how many user-facing features are dependent on the framework, and how important are they to the business? Are there other things the business can focus on while they wait for your team, or do they need the support as soon as possible? In all cases, the right balance between custom and off-the-shelf software will need to be identified based on your specific timelines and use cases, but if the urgency from the business is high, it's essential to keep in mind the importance of demonstrable progress in order to maintain customer relationships.
One additional related aspect to consider when deciding between a slower idealistic solution and a faster pragmatic one is how your architecture problem fits into the overall context of your industry. Are you building something specific to your company's mission, something novel that could propel you ahead of competitors? Or are you building something that supports your company's platform, something that a different industry would specialize in? A good example of this is in the healthcare industry: if you are building a document storage solution for an Electronic Medical Record application, it probably makes sense to utilize existing technologies as much as possible to get the needed support in place more quickly. Storing documents in an efficient manner is not something entirely specific to your product or even to healthcare in general, and is not something your company necessarily gains credit from excelling at. On the other hand, if you are building a system that ingests and standardizes patient genomic data - something very specific to the healthcare data industry - you should be able to justify building a higher percentage of your architecture from scratch, even at the cost of a slower time-to-market.
Long-Term Maintenance
The cost of maintenance of your architecture over time is an additional factor to consider when making design decisions. This includes anticipation of any testing difficulties, employee attrition, and future tech industry changes. All types of design decisions - from simplistic to complex, built-in-house to third-party - have their share of implications in each of these three areas.
Regarding testing, it is well known that the output of a software company depends directly on the efficiency of its QA team. No matter how quickly your software developers can build a product, it can't be released to customers until it is thoroughly tested and certified. Therefore, even if you cover all bases regarding receptivity and speed-to-market—you have a great architecture, churn out results quickly, and keep developers happy—you will not find success if the software is very difficult to test.
In terms of employee attrition, you'll want to consider the risks and costs of your technology choices if any of your current employees were to leave the company. What specific skills and domain knowledge will your design require, and how much value would be lost if one of your employees were to leave? The amount of risk here probably grows in proportion to the percentage of your technology which is custom-built: the more your own developers build, the more you will depend on them. The risks of losing Subject Matter Experts can be mitigated by sharing responsibilities across a group of individuals rather than delegating them to a single person, but any new developers you hire to replace departing ones will still need to come up to speed on the tech stack you've chosen. This re-emphasizes the importance of receptivity from developers both inside and outside the organization, resurfacing questions such as: will you be able to hire strong candidates to work on the design, how fast will they overcome the learning curve, and will you be able to retain them?
Finally, when creating your design, you'll want to make it flexible in order to allow for changes in the technology industry over time. Here, opposite from above, the amount of risk grows in proportion to the percentage of your technology which is obtained off the shelf, including both commercially licensed and open source software. It certainly is too difficult to anticipate exactly where technology trends are heading in 5, 10, or 20 years, and many technologies that seem promising turn out unpredictably to be short-lived fads. You can't expect to make a perfect choice of third-party software if you choose to go that route. But instead and at least, you can think ahead of time about whether your software design will force you to be tied to a very specific technology.
For example, consider a Cloud-based file storage solution such as AWS S3; is there any part of your design that is specific to AWS? Or could you switch to a different Cloud provider relatively easily? As another specific example, I once worked for a company whose entire application relied very heavily on Google Web Toolkit (GWT) for the UI display and data transfer between the front-end and back-end layers. The entire architecture depended so directly on GWT infrastructure that separating the backend into independent services proved to be a multi-year, multi-team task. The more vendor-agnostic your design is, the more easily you'll be able to avoid getting stuck on an outdated platform, and the more quickly you'll be able to upgrade or pivot your underlying infrastructure as technology changes.
Conclusions
Software architecture in the business world cannot be created in a vacuum, and a solid technical foundation is not enough to ensure success. When creating a software architecture plan, it's important to keep in mind the non-technical and cultural implications of the technology, including receptivity, speed to market, and long term maintenance. These implications will be carried forward in the company for years, impacting developers, managers, product owners, users, and maybe even executives. In a way, they represent your own personal legacy within the company. Making these types of decisions is an incredibly difficult task, but if you're going to achieve success, it is imperative to keep in mind the overarching culture and context.
Abigail Walker is an application software engineer at Ontada.
No entries found