Gather a DevOps or data science team to define the architecture for a new application, data lakehouse, or AI service, and you’re likely to run into debates on technical approaches and disputes on platforms.
When reviewing implementation options, teams will question which standards
apply and are key factors in making technical decisions. The solution
architect’s viewpoint differs from enterprise architecture, the devops lead
is opinionated on specific platforms, and product management is trying their
best to persuade the team to leverage
low-code platforms
rather than custom-code new solutions.
When architecture and solution debates arise, how effective are teams in making efficient and prudent decisions? Do they make quick choices without considering the facts, risks, and opportunities? Or do teams fall prey to analysis paralysis, looking for more details, better data, and more evidence, aiming for the most thorough conclusions?
One last question. How much technical decision authority does the CIO, CFO,
and other executive stakeholders award teams versus others that require
higher-lever review and approval?
Architects play significant roles in leading digital transformation
and
reducing technical debt
when they understand the big-picture business strategy and have clearly
defined responsibilities.
Define a framework for making architectural decisions
With dozens of platform types, methodologies, partners, and products,
architects are far less likely to partner with agile teams to achieve 100%
consensus on a solution’s architecture. Even IT organizations with strict
standards or mature platform engineering practices should consider
evaluating new options that offer new business benefits, end-user
innovations, or improved developer experiences.
In Digital Trailblazer, I wrote, “One of the key differences between great and average teams is
how they create and manage conflict. Teams that can learn how to step on
each other’s toes without hurting anyone are likelier to learn from each
other, handle stressful moments, have fun, and create a culture that more
people are excited to be a part of.”
So, how should teams facilitate debates, navigate disputes, and make timely
decisions on solution architectures?
“I handle disputes by defining clear lines of ownership of ultimate decision
making via the RACI framework as well ensuring we have a culture of disagree
and commit, so we don’t block ourselves from delivering,” says Dana Lawson,
CTO of Netlify. “The best advice I
give to IT leaders is to clearly define the problem you are designing for
and do the due diligence on the scale and speed you anticipate. From there,
it’s best to ensure you have processes in place that explicitly call out who
can make and own decisions.”
An architectural decision framework communicates to agile teams where they can self-organize around solutions and when to solicit architectural advice. It helps define a process for reviewing, experimenting, producing, and managing the full lifecycle of evaluating new technology platforms.
5 questions to review when debating solution architectures
Debates can lead to disputes when people working through a design can’t
appreciate their colleagues’ role and vantage points. So, a key starting
ground when gathering to discuss architectures and solutions is to remind
everyone to have an inclusive discussion and that everyone’s opinion is
desired.
Clearly defining the problem statement and any non-negotiable requirements
is an important starting point. Avoid solution bias, which can happen when a
problem statement is crafted to support a desired solution rather than
defining a
vision statement
based on business and end-user needs.
With a problem statement defined, I recommend answering these five questions
to help sort out the pros and cons of different approaches. Architect and
agile delivery teams should answer these questions once and update them for
solution-specific considerations.
1. Who is most directly impacted by the architecture?
To understand tradeoffs, a best practice is to define the people most
impacted by the solution. Be more specific than just listing out all the
end-users and business stakeholders, define key personas, and include people
in IT and other departments supporting the solution. By identifying these
personas, the architectures and solutions can be evaluated by their impacts
on each persona.
For example, one solution may offer customer benefits but may have costly
workflow changes in customer service and require establishing new DevOps
skills. Dimensionalizing tradeoffs by these personas can help flush out
priorities, opportunities, and risks.
2. What are the short-term and longer-term consequences?
Once people/persona dimensions are defined, I recommend reviewing
architectures along with timeframe considerations. Specifically, what’s the
6-12 month impact versus longer term 2-4 year benefits and risks?
Architects and agile teams should define short-term business values and
strive for speed-to-market, ease of use, simplified change management
considerations, and other factors that might impact development timelines
and end-user adoption – versus longer-term factors that include strategic
benefits, compliance risks, financial ROI, and operational considerations.
3. What factors highlight the tradeoffs between solutions?
With people and time dimensions understood, the team should consider factors
that help characterize the tradeoffs between each solution. I recommend
drafting 1-2 primary questions around the prioritized factors, which can
include
- User experience for the system’s primary end-users
- Developer and operations experiences for people building and supporting the system
- Extendibility and flexibility of the solution to support ongoing changes and enhancements
- Testability capabilities for creating environments (for example, sandbox and staging), integrating with testing platforms, and developing test data sets
- Data factors around what data is created, processed, and accessible from the system
- Intelligence factors, including analytics, automation, ML, and AI differentiating capabilities
- Personalization and mobile capabilities to improve both customer and employee experiences
- Security considerations in areas such as roles, entitlements, and encryption
- Integration factors around workflow, data, and identity
- Low-code, no-code, and other self-service configuration capabilities
- Partnering factors so solution providers and experts can accelerate development
- Internationalization requirements around language, data governance, and localization
- Compliance functions around audit, controls, accessibility, and regulatory non-negotiables
- Operations around physical systems, including installation, troubleshooting, maintenance, repair, and replacement
- Hosting options, including public cloud, data center, edge, and managed services
- Scalability to support usage, data, and operational growth
- Performance and reliability factors to meet targeted service level objectives
- Change management factors, including training needs and documentation quality
- Ecosystem factors around partners, developer community, and third-party capabilities
- Cost considerations that factor in initial investment and ongoing operations
- Legal considerations around customers, partners, data, brand, and other risk areas
- Complexity factors that require new skills, departmental workflows, and policy creation
These factors are not prioritized, and my list of 22 factors is impossible
to evaluate in a reasonable amount of time. Architects and agile teams
should consider the minimally viable architectural evaluation (MVAE) for the
architectures and platforms they are considering.
Trying to plan the perfect architecture is futile, and architects should scenario plan what can go wrong with their
best-laid plans. They should also consider these
12 signs of bad application architectures
when planning new ones.
4. What’s the impact of making the wrong decision
This forward-looking question flushes out the unknown and risks with any
solution.
What happens if DevOps or data science teams go from proof of concept (POC),
to pilot, and onto production, only to recognize that the architecture and
platform are dead ends? How easy is it to exit these platforms and move to
alternatives if that happens?
Identifying an exit strategy for any platform is a critical review because
even when architectures and platforms succeed in delivering business value,
future architects will need to consider how to manage the architecture’s
technical debt and how to migrate if it falls to legacy status.
Having tools to import and export data, APIs for all critical low and
high-level functions, and a strong ecosystem of partners are key factors
when evaluating exit options.
But these aren’t my most important factors.
Contact me
if you want to know the most important factor when evaluating platforms
around exit considerations.
5. How can architects and agile teams plan an incremental evaluation
I advise organizations to prioritize the 22 factors and review exit
strategies as key areas to debate and identify where there are disputes.
Agile teams should itemize the areas of uncertainty, unanswered questions,
and identified risks on a backlog. Once grouped and prioritized, the team
should conceive proof of concepts and follow a
continuous agile planning process
to evaluate the architecture and platforms.
I first wrote about this
agile approach to architecture
in 2013 and provided more process specifics in my first book,
Driving Digital. My company, StarCIO, can also organize a
1-2 day workshop on agile architectures
and selecting platforms.
The bottom line is that architectures aren’t one-and-done decisions.
Organizations can turn debates and disputes into an incremental architecture
decision-making framework by forming a collaborative team, encouraging a
debate on MVAE, and leveraging an agile architecture planning approach.
Digital Trailblazers! Join us Fridays at 11am ET for a live audio discussion on digital
transformation topics: innovation, product management, agile, DevOps,
data governance, and more!
No comments:
Post a Comment
Comments on this blog are moderated and we do not accept comments that have links to other websites.