We often see that in discussions amongst practitioners where ideas like basic authentication, API keys, SAS tokens are given credence, weakness introduced to overall security posture isn’t identified or known, and special security attention isn’t given to all facets of what’s being produced.

Often solutions will be designed that have cloud platform limitations requiring public endpoints to the cloud in order to use certain technology or patterns. Architects should know this going in and in such cases discuss viability with the security team, but sometimes they miss it or they misunderstand the security implications and it flies under the radar.

We’ll even see architects put together a solution with a complete and intentional disregard for security controls in order to meet a timeline. That’s bad.

Security teams have to provide gating here, but a poorly thought out solution that doesn’t take security seriously should never be presented to security teams to begin with.

It’s up to individual practitioners to seriously up their security game and it’s up to orgs to help incentivize this and maintain a higher baseline of overall security knowledge across its practitioners. Adding security engineers and security architects into cross functional teams may also help improve the baseline.

That being said, non-security team members shouldn’t be making authoritative decisions that affect security postering without consultation from security teams and security experts. There’s a different between having security knowledge and being a security expert (as we expect Security architects and security engineers to be). To be an effective practitioner absolutely requires building solid relationships and keeping open lines of communication with your security experts.

Program sponsors and project managers also need more awareness and to understand that “security” is an on-going activity. If a project has met all security requirements 5 years ago, it doesn’t mean they meet the security requirements today, and thus need to work that in to their timeline and cost projections.

“I thought security was done already?”.

—No, it’s never done. Did you budget for on-going security posturing? No? Why not?

You can certainly understand the perspective of different stakeholders who want to deliver and want some predictability of what’s required from a security perspective, and that can be done but alignment and expectations need to be set as early as possible, so that it can be incorporated into plans.

How long can organizations continue to operate on a model that requires security risk acceptance upon security risk acceptance because proper care and due diligence related to security wasn’t undertaken or budgeted for at the right moment?

At face value, it’s not the full story and may only be a few aspects, or potential faults, in what may otherwise be effective architecture. Architects come from all different perspectives with different ways of seeing things and different approaches to problems. They come from different backgrounds from different organizations which helped to mold their worldview of architecture.

Some people may be better at delegating, leading, and inspiring people to do their best work whereas others may be more intense thinkers and problem solvers yet still good at collecting and then conveying information to the right people. Some people may be exceptional yet still have communication challenges or perhaps inexperience with very fast moving operations which leaves them struggling to maintain alignment without having additional support. Others may have most of the high quality attributes necessary to be an effective architect, yet still with opportunity to grow.

To be clear, there are a core set of competencies that architects need to have to be effective, and architects should be held to that standard, yet as we see above there are ranges of qualities between different architects.

An effective architecture practice needs competent architects, but it also needs culture, methods, rules of engagement, gating, and operating procedures in order to be effective and to establish a baseline of how an effective architecture practice operates.

You don’t want your architecture practice to be too rigid because rigidity actually slows competent people down, but you need to strike the right balance in defining your architecture practice to ensure a minimum level of quality outcomes from your diverse architecture team, and this is not a one size fits all approach.

For example, operating procedures and gating can help ensure that accountability is properly delegated to a SME for implementing certain significant facets of the architecture. Security teams can take ownership of security facets of architecture with gating processes requiring sign off by security team and CISO to move forward with security designs which also serves to shift accountability for those controls to security teams.

Workflows can be introduced and systemically enforced to ensure that architecture or the delegated SME reviews completion of work that are significant to the architecture, or review, by process, work that is significant to the architecture that is not complete within agreed upon milestones – this sets the stage to identify risk in-flight and to ensure mitigation is in place (business risk acceptance, re-work, re-design, etc).

These are a few examples, and they may or may not be necessary depending on the organization, its culture, its business, and its historic operating success.

Establishing the right balance of practices within your architecture practice is an iterative journey which requires some amount of experimentation and validation. You may have to remove things that are not working and slowing the team down, only to add additional refined practices later that help establish a minimum standard of quality outcomes.

It’s important to observe how things are currently working and provide a qualitative measure to them in order identify areas of potential improvement.

Brainstorming and alignment with the broader team will help provide a mutual understanding of why things may not be working well, or even provide clarity as to the things that actually are working well but may have been perceived to not have been working well — of course this leads to discussions on perception and how to improve perception. This will lead to more effective iterative practices within the architecture practice.

“Performance” is one such NFR that requires a broad and clear understanding across your entire program. A good architect will make sure that they have the right information and projections from their reliable and accountable business sources in order to make determinations about technology and patterns to be used to support those projections. They will then translate this into technical data to support design decisions relating to performance, load, and scale.

A good architect will also validate this information because, like I always say, not only are technical leaders accountable for their decisions, they are accountable for the quality of information that their decisions are predicated on.

Architecture and design work takes these NFRs into account, but NFR requirements aren’t ever met until the systems are built and validated.

Everything from architecture, to build quality, executive sponsorship, and project management could reduce the likelihood of meeting performance or other NFR objectives.

The following points are crucial to ensuring your performance objectives are met:

1. Consistent and clear communication about the need to meet performance objectives and what it means if you don’t meet them.
2. Clearly articulate the risks. Is your biggest risk that the system will just run a little slow? Is it something that is acceptable? Or, is the risk much greater and not meeting the demands of the system due to poor performance means system crashes repeatedly under load leading to failure, service restarts, and information loss.
3. Alignment on risks with program team, business, and sponsors along with what the business impact is.
4. Documentation that remains up to date, widely distributed, and work tracked as part of your ALM/PM/Agile system (Jira, DecOps, etc)
5. Development leadership to ensure everything going into the system has been implemented in a way that will help meet performance objectives (example: leadership to the development team so that they understand the importance of and usage of parallelism, multi-threaded processing, async operations, and batching, as examples)
6. Testing in place, planned, and aligned with the program to validate performance of components as they are built. Don’t save this until the end of the program.
7. Systems and teams in place in order to orchestrate the required performance and load testing of the entire system — for example: Do you need new enterprise performance testing software and expertise? Can you use existing in-house resources and systems?
8. Defined and aligned on minimum metrics to meet, that if not met, could delay the promotion into production.
9. Ensure you (or the lead architect for the program) has a seat at the table when meeting with program sponsorship and steering committees in order to provide a balanced perspective on the intersection of the business value to technology and any risks entailed. This also ensures that clear and accurate messaging is propagated and not filtered through the lens of the business or project management.
10. Architecture and design work that specifically calls out where patterns and specific approaches are to be used in order to meet performance NFR objectives, and that specifically points out the areas of the system that are most critical for performance work.

As you see, there are a lot of moving pieces involved in ensuring you’re going to end up with a system that adequately handles the load, including peak load, and performance needs.

There are so many projects that fail because there wasn’t enough consideration and alignment to the need for performance and scale from either architecture or management. I’ve seen projects (not my projects) go into production and fail the first day because it just couldn’t handle the load requiring the project to be pulled (very expensive) and re-worked for 6 more months – the rush to production didn’t pay off, and it’s (un)surprising how often this happens.

It’s too easy for many architects to be oblivious to or let this slide under the rug, not be pro-active, and not call out bad behaviours, anti-patterns, or lack of progress in meeting performance NFRs.

Naturally, if a program fails and performance is to blame, we look at the architect and the architecture — with good reason because one of the responsibilities of the architect is to make sure we have alignment across all of the moving pieces required to make sure NFRs like performance will be met and are being met within the architects domain. The architect is a primary strategic and technical stakeholder who sets the technical direction along with technical leads and SME’s who also have responsibility as per their direction and vision as aligned to the architecture.

Architects need to be pro-active, and they need provide leadership. If something becomes critical, for example, the project team removes performance testing from scope or continually defers it for short term gain, then it needs to be called out, and serious discussions need to be started about how we can reasonably meet performance requirements and maintain a steady pace to production.

Some architects will say, “It’s not my job. My job is to provide a design and if it’s not followed and they want to do something else then that’s up to them”… or… “I don’t want to speak up because I know they don’t want to hear it”…or…”nobody else is bringing it up or concerned, so”… These are all signals of avoidance, and this is a bad value proposition. It’s the kind of(un)value proposition that leads directly to program failure due to the lack of leadership coming from architecture.

Part of an architect’s job is to lead and to ensure and maintain alignment throughout a program up until production launch and even beyond.

As an architect, you want to win. You want things not to fail.

Of course, within your realm there are other people that make decisions and provide leadership also, including executives. It’s completely reasonable within their role to be able to make decisions even if other people, including architects, disagree with them.

These decisions could negatively impact the vision or reduce the likelihood that NFRs are met (to keep an example within context) but sometimes these decisions need to be made, so it’s important that in these cases that the architect works with the program team to ensure that the decision is predicated on accurate information, and to ensure and validate that the appropriate risk acceptance is to be in place and documented by the program team. Many people think accepting performance risk means accepting that the system will run a little slow — that’s a huge fallacy. Architects must educate and clearly articulate what it actually means – or could mean. “There is a 25% chance based on recent testing that we’ll intermittently lose customers production data in a 3 month period if we go into production like as-is” is a completely different paradigm than “it will just be a little slow”.

Ensuring risk acceptance where it’s needed when a solution will not be compliant with the architecture or agreed upon NFRs is a responsibility of architecture and not something that can be relegated to program teams at their own discretion. Architects own the vision of how technology is going to achieve business success and they own the core facets of the architecture required to achieve that success, and therefore they are accountable to identify and raise the issue when core facets of the design are not implemented.

Going into production with missed requirements requires that the appropriate business sponsor has a clear understanding and is willing to accept the business risk, and therefore adequate translation of what the risk means to the business is required. There may be some amount of risk for technical teams to accept (such as increased support required in the event of failure), but remember that it’s the business that ultimately accepts and takes ownership of the risk for the business impact and not the technical leads or teams.

Enjoy

-Dan

It’s the gaps and the blind spots in a seemingly good architecture that will completely de-rail an entire program.

Gaps in an architecture sometimes even slide through without scrutiny. Sometimes others miss them too. That’s not good.

Architects have to be on top of it and have methods to look at things from different perspectives and really think about what could go wrong. They need to understand their level of awareness of the technology and business domains. They need to bring in others to scrutinize what they are doing and ensure productive dialogue about the approach.

Otherwise, you are facilitating gaps and not being of good service.

Examples….

It could be as simple as a missed opportunity to ensure authentication and security standards are incorporated in the solution. CISO fails to sign off just before go-live. I’ve seen it. I’ve seen projects go back to development for months because architects’ missed core security controls in the design. It passed scrutiny the first time around, but the architect left out key details that should have been known and brought to light, and if they were they’d have been corrected early.

Or, there could even be a gap in the details that have a significant impact on the design. Let’s say you have tightly coupled HTTP components that the architect designed to be strung together. The architect knew that some of those components would be long running by design but now doesn’t understand why it’s failing in testing when processing runs long. The timeout configurations on the client and service were adjusted accordingly, but it still fails.

The failure is that the architect didn’t have the knowledge that because these are cloud platform components the built-in load balancer times out after 2 minutes regardless of what the client or service time out is set to. An entire design that looked good on paper has to be re-worked after it’s been developed because the details were not well enough understood by the architect who put the design together.

Be careful out there. Be self-aware. Know your stuff.

These are sometimes honest mistakes. Sometimes, negligence.

Overcoming bias is important, and even those who succumb to the fallacy of “priding themselves” in their “decision making” may have all kinds of different biases that are oblivious to them. It’s important to develop self awareness to keep this in check, and it’s only possible if we first recognize that having bias is an inherent attribute that can negatively impact the quality of our decisions.

To help overcome confirmation bias, it’s important to:

• Seek out diverse opinions: Be aware of tendencies to seek confirmation. It’s better to focus on validating the strength of your decisions with competent people who think differently and have diverse sets of backgrounds. Avoid tendencies of solely seeking out validation from those within your own thought-bubble. Once you’ve decided to seek out diverse opinion, it’s important that you are also open to them.
• Actively work to influence the culture to promote, open dialogue, disagreement, and critical thought: Having critical thinkers who understand how their biases can negatively impact their decisions is one thing, but influencing the entire culture is another thing all together which helps multiply its effectiveness systemically across the organization.
• Be objective and self aware: Objective data and measurement provides good data points in which to base decisions off of, however it’s also easy to dismiss otherwise objective data when it doesn’t align with your pre-conceived ideas. Just as it’s important to be objective, it’s important to take a step back and assess and validate if you are actually being objective or further succumbing to confirmation bias under the guise of being objective.
• Actively consider the other side of the argument: Invite people to contradict your position and don’t fear disagreement. Of course, people who disagree with you may also have confirmation bias, so it’s important that all discussions are rational and predicated on the idea that the purpose is to move froward with decisions in the most sound and responsible way.

As we move along the path of significantly reducing confirmation bias, it’s important to remain rational, objective, self-aware, and to not introduce new paralysis into the decision making process due to the heavier burden of reducing bias from the equation.

The key is to work smartly and to get to the place where removing bias is inherently part of the decision making method. Don’t disregard the need for time-boxing decisions. Identify the strength of decisions weighted by what we know and what we don’t know. The higher the significance of the decision, the higher the bar should be established in terms of validating and ensuring that bias has been minimized as much as possible.

People who are highly skilled decision makers know their strengths and they also know when their strengths could impede objective decision making. They are also highly self-aware which when combined with their other strengths allows them to effectively understand things objectively and make good decisions. One may be carefully skilled at debate, articulation, and crafting speech to influence outcomes, but these attributes on their own don’t make for an effective decision maker without competence and self-awareness.

Architects

As Enterprise and Solution Architects have the ability to steer technology direction to help organizations meet strategic outcomes, getting a hold on confirmation bias is paramount. Additional consideration regarding our decisions needs to be had and we need to be methodological about it.

Hyper-focus is when someone has a vision or desired target state and proceeds to be hyper-focused on this singular outcome or idea. Hyper-focus on single outcomes such as a successful product launches or business directives are fine as long as adequate attention is given to risks and constraints. However, hyper-focus on outcomes that are predicated on self-serving ones agenda or hypotheses lead to weak and faulty decision making.

Imagine EA recommendations for moving ERP systems away from monolith on-premise solutions towards cloud integration and PaaS models. One EA may consistently consume and relay information that only validates his or her belief that this is bad due to excessive operational costs, lack of data ownership, jurisdiction of data issues, change of vendor, and inherent cloud security risks. The more balanced EA approach is to consider those things, understand the weight and impact, understand where these issues can be mitigated, and rationalize the advantages of a cloud approach over the long term. However, if left solely to the devices of the first EA, the narrative pertaining to PaaS models would make it, unfairly, look quite bleak with the resulting directives having quite a negative impact on the organization over time.

In addition to the ideas presented above, the following positive-patterns, specific to technology and process, can help ensure confirmation bias is minimized within EA disciplines:

• Don’t sugar coat information based on what you believe people want to hear. It’s important to be as accurate and precise as possible. Sugar coating information is a form of confirmation bias as you are assuming you know what the other person wants to hear and are tailoring your response towards that.

• Create an effective ARB gating process which includes the most competent thinkers across the discipline. Be wary of “the elders” approach where you limit questions at the gating process to a small handful of approved people. This is akin to always asking the same people to challenge or help assess the quality of your decisions which can reduce diversity of thought and create thought bubbles.

• Don’t seek validation. Objectively seek out critical questions and the correct path forward.

• Don’t assume that what worked in the past will work in the future, and be wary about making decisions based on this presumption.

• Avoid getting stuck on legacy or expensive ‘technology stacks’ largely premised on the relationship with the technology vendor.

• Avoid decisions on technology that are largely based on an architect or a decision makers familiarity with that technology. These decisions may not inherently be in the best interests of the organization and should be scrutinized further. Decisions predicated on the organization’s capability to operate and deliver should be the focus instead.

• Appreciate when given information that is contrary to your beliefs or position and proceed accordingly with an objective evaluation.

• Decisions often need to be made even when we don’t have all of the facts. Ensure that any decision made is caveated with the weight of the decision given what we know and don’t know. Be objective and avoid rash choices which may solely be predicated on our own confirmation bias.

Architects have the capability to impact the business in the long term to help them form and realize their strategic vision.

Building a reputation on effectively serving the needs of businesses we partner with will also yield fruits of satisfaction and more “win-win” business over time.

Here are 6 ways architects can demonstrate that we are acting in the best interests of the client and in a fiduciary way:

• Do the due diligence to truly understand your clients needs. Jumping to decisions or conclusions without doing so may be inadvertently predicated on bias or predicated on ones own business interests rather than interests of the client.
• Be transparent of risks, benefits, omissions, and limitations. Omissions of key information, either intentional or not, can ultimately influence decisions without the client understanding the full picture.
• Be objective and open yourself up and invite tough questions from the client. This can validate your own objectivity and help ensure the client is comfortable that you’ve been as objective and have done the work.
• Respect confidentiality and intellectual property. Understand what is confidential and what is not and respect it. Respect NDAs and legal agreements. If you are not comfortable with an NDA the onus is on you to either work with the client to modify the terms before signing or to part ways without an NDA. Once signed and executed, respect it.
• Be fully transparency on your decision making method. Provide the client with full transparency on how you came to decisions or recommendations justified with evidence.
• Identify when recommendations have been made on omitted or unknown variables.

There may be cases where clients partner with IT services firms that do have vested interests in continuing business or recommending software and additional services (upselling). This is not inherently wrong as long as the interests are disclosed. What is inherently wrong is not disclosing these interests and carrying on business in a way that is self-advantageous at the detriment to the client.

An abundance of business is derived from ethical business.

“I don’t want to invite you to the meeting because it will waste your time”

This could just as easily be said in a variety of different ways, but ultimately my friend was dismayed and discouraged.

My friend is not subordinate to the gatekeeper, is not a low performer, and is not someone who needs his work directed or orchestrated. In other words, he’s accountable for his delivery, and he owns it.

Some of the initial thoughts that crossed our minds in terms of how he could respond, included:

“What makes you believe you are the arbitrator of what is a waste of my time and what isn’t?”

“Why do you feel you are in a better position than me to understand what the best use of my time is?”

Of course, these thoughts came up in our private discussion, but we don’t believe that asking these questions is going to achieve the outcome he would like, and in fact could create more friction. My friend and I agreed that however valid and legitimate these questions appear to be, there was absolutely no value in asking them.

This demonstrates our initial knee jerk reactions, but when we take a step back and we think critically and objectively, we disregard them in order to come a better conclusion and a better way to move forward.

We understand that any time we create a meeting we select who we invite based on who we believe needs to be there or who we want to be there. That’s reasonable. If we have team members of whom we are accountable for their delivery, then selecting who attends can be a strategic decision, but we need to be careful of overreach and exercising control too tightly.

We both agreed that the meeting organizer appears to motivated by some element of having control rather than what’s in the best interest of the organization. Of course, we don’t know the exact reasoning and we can’t be 100% conclusive about this at this point, but we left with this likely conclusion based on previous interactions, and we had determined that there is no possible way for the meeting organizer to have the kind of insight into what is a waste of time for my friend and what isn’t.

We also considered that the meeting organizer may have other reasons for not including my friend in the meeting, but for some reason was not forthcoming about it. We talked about how it’s not probably personal but may be just politics.

We realized that the question of “why does the meeting organizer want this level of control?” became pretty irrelevant. My friend is in a position where he believes he can gain and provide significant value by attending these meetings, but he is blocked by a meeting organizer who’s walls are built up way too high.

We believed the best course of action was to have an honest conversation with the meeting organizer about my friends value proposition rather than focus on why the organizer wants this level of control. There is too much information that is being held back by the meeting organizer, and a frank discussion needs to be had. This should help remove any walls the meeting organizer has built up regardless of if those walls are justified or not, and allows my friend to start at a neutral place for the topic of discussion.

Additionally, my friend has contingency plans in place which include conducting his own meetings and having additional discussions with key people to get things going in the right direction. It’s always best to plan a few steps ahead and be intentional and strategic about it.

These are the day to day politics of any organization that need to be navigated. It’s important to meet and discuss and build relationships to help move things along. Generally, be careful about trying to exert control over others; even in situations where you believe you are well intentioned, it may come across as insincere or patronizing. With a little tact, conversation, and relationship building, walls can be torn down, relationships can be built, and people can move along in harmony within well functioning teams.

It’s important for organizations and architecture teams to align on nomenclature and common understandings of these concepts. I stress this importance because even things that should be straight forward don’t always have a common understanding across the board; for example, **business continuity recovery objectives may imply different things depending on ones understanding or misunderstanding of the concepts.

When these types of differences in understanding occur, the organization is at a disadvantage due to the spin and friction that comes with misalignment. People often tend to misunderstand what business continuity is , and they may misunderstand the relationship between business continuity objectives and DR. Other times, there are gaps in knowledge; I’ve seen architects put together comprehensive solutions to support DR without any knowledge or understanding of what business continuity is. This creates a lot of risk and re-work, but with a little effort to ensure common understanding and alignment, these risks can be removed while ensuring the organization has a standard understanding.

Business Continuity

Before we can understand DR and it’s purpose, we have to understand business continuity and the business continuity plan (BCP).

Business continuity is the continuation of critical business processes during a major outage or catastrophic event. It requires ensuring that there is a plan to support critical business processes. DR exists to supports business continuity, but DR is not business continuity; it’s only a facet of business continuity.

Business continuity has core recovery objectives and SLAs, with specific importance to the RTO, and RPO objectives.

• RTO – Recovery Time Objective – The planned for recovery time to restore a critical business function.
• RPO – Recovery Point Objective – The window of acceptable data loss that supports the business in the event of a major outage or disaster.
• MTO – Maximum Tolerable Outage – The amount of time in which business processes and supporting systems, if required, can be restored along with data or information required for those processes before there is an unacceptable business impact.
• MTDL – Maximum Tolerable Data Loss – Maximum amount of data loss, as expressed in a window of time, that the business is able to accept.

You may see organizations use different terminology for the above terms; example: instead of MTO, they may use MAO (Maximum allowable outage) or MTPD (Maximum tolerable period of disruption), etc.

RTO is the amount of time it takes to recover critical processes. This does not mean recover systems or recover all systems. The SLA to bring up the supporting systems may be different and longer than the service objective to bring up the critical business processes. The business continuity plan (BCP) would define where manual or alternate processes can be used while underlying systems are unavailable.

From a BCP perspective, having a short RTO for critical processes while expecting systems to be available later-on is advantageous from a cost perspective and allows business teams to keep the lights on regardless of the current state of underlying systems. However, manual processes to keep the lights on during this outage will require data reconciliation later which has its own set of costs and complications. Business continuity generally is balanced in ensuring that the business can continue to operate during a disaster scenario and preferably with as many systems it needs as soon as possible.

Although systems can be designed to be fully recoverable very quickly, that typically comes at the price of significantly higher operational costs which can be prohibitive for many organizations given the low risk of disaster coupled with the ability to keep the lights on with alternate processes, and less systems, as per a well formed business continuity plan.

Where does DR fit in?

A DR plan is part of the organization’s business continuity plan and exists to support business continuity during a disaster or large outage scenario. DR stands for Disaster Recovery and literally refers to the execution of the DR plan and sometimes generally used as an umbrella term encompassing everything required to make the DR execution happen. A DR design diagram isn’t in itself DR either although architecture and design may be required to support the DR plan. A DR plan has defined processes, procedure, and role definitions used to bring systems back online and restore data within a required SLA.

Inevitably, as an architect, you’re going to be asked about DR. These questions will be familiar to you, “Does your solution support DR?”, “Where is DR?”, “Where is your DR diagram?”, etc. These are valid concerns and valid questions, but sometimes can sow confusion as well.

When people ask an architect for “DR”, what they are trying to understand is how the solution accounts for the technology, software, and processes required to execute the DR plan. They want to know that you’ve done the due diligence to be satisfied that DR will be supported with the design.

DR aims to restore system functionality to support the critical processes identified as part of BCP. System restoration may be staggered and done in phases dependent on the priorities outlined in the DR plan which is informed by the BCP.

A “DR design” or “DR diagram” supports the DR plan and the vision to support the technology required to execute DR, but a DR diagram is not DR nor a DR plan. DR is the actual execution of a DR plan; organizations should be clear on this terminology.

A DR diagram will outline how the solution will support the DR plan, including, where backup and recovery can be employed, rebuild, active-active, geo-replication, and synchronization between data centres will occur in support of DR.

Understanding DR vs BCP objectives

Restoring business processes is not the same as restoring systems, and the nuance here is that systems and applications can have different recovery objectives than the business processes that they support.

RTO is a business continuity objective, and because BCPs can outline alternate business processes in the case of disaster, it would not be a true statement to say that the schedule to bring up an underlying system that supports a business function is the same as the RTO for that business function as outlined in the BCP. This is something that architecture and technology teams sometimes get wrong, and getting it wrong could mean over-building a solution where overbuilding costs significantly more in initial costs and in ongoing operations.

However, if critical business processes are dependent on underlying systems, that dependency is part of the BCP and would then inform the DR plan. This could mean that it was imperative to bring up specific systems within the BCP defined RTO to ensure critical business functions could resume as there is a direct dependency on the system that is defined.

Are High Availability and Backup also DR?

High availability and backup are not DR but they can play a role as part of DR planning.

High Availability (HA): A solution that ensures a high uptime during regular systems operation that typically incorporates redundancy, failover, geo-availability, and capacity management.

Backup: Backup strategy, technology, and processes to facilitate backup and restore functions.

It may be convenient to think that HA or Backup will inherently provide underlying technology to provide DR capability, but DR planning requires much more due diligence.

When we consider DR we have to be intentional about the technology and how that technology specifically supports the DR plan.

Restoring from a backup can be used as part of a DR plan and it often is, but other technology options exist that need to be considered, including, geo-replication of data in real time, as an example.

Building a highly available system could lend itself to DR as well, but it’s important not to conflate high availability (HA) with DR. High availability is an availability attribute but not a DR or BCP attribute. HA will provide a guarantee of a high percentage of uptime during regular operations, but it does not make the solution inherently DR or BCP ready. HA covers normal operations and not BCP recovery scenarios.

While it’s true that if you have active geo-replicated systems, you may be able to continue to seamlessly operate from a different data centre in a geo-replicated environment given a disaster at a single data centre, but there are other considerations such as capacity and availability reduction and impacts to downstream processes. BCP plans will also cover scenarios where the entire system goes down across data centres. For example; a software bug deployed to all geo-repliacated data centres could bring all the data centres down at the same time, so it’s not good enough to say we have DR covered because we are geo-replicated.

Therefore additional consideration is required in terms of how DR will be supported in relation to BCP. Also, remember that the DR plan must be directly supporting the BCP, and the goal of DR isn’t to restore 100 percent capacity nor is it meant to restore all systems that are running during normal business operations. As DR is always informed by business continuity, teams developing DR plans and DR designs work with and are informed by business continuity and the BCPs prioritization of critical business processes mapped to systems.

There will be completely different approaches to DR given different RPOs and RTOs. To achieve a near zero RPO or RTO requires much more careful planning and a much costlier implementation. Conversely, an RPO and RTO of 24 hours affords an organization much more leeway for DR planning. In 24 hours, data can be recovered from backups and new servers and software can be manually provisioned in data centres. Ultimately, these metrics are decided by the business and driven by business continuity planning teams, have executive alignment, and will vary across organizations given the business impact, resource/people capabilities, technology capabilities, and mitigation options available.

He made this statement back in 2020, and it has stayed and resonated with me since, but we don’t need to be making 25 million dollar business deals to heed this advice.

In business and in the workplace we are negotiating and agreeing on ‘deals’ all the time. We’re negotiating a path forward, making decisions that impact other people and their work, etc.

Organizations are complex eco-systems with various factions each applying their own amount of political pressure. When working to establish a path forward we need to please sponsors and stakeholders, and we rely on people to execute and complete the vision. We need to motivate and execution is paramount.

Workplaces will also struggle with the added bureaucracy of hierarchy. You can reasonably say that people in higher levels of authority need the support of other teams and subordinates. Unlike a business deal, where one party can walk away if they aren’t satisfied with the terms, the nature of the relationship is different within an organization. Unfortunately, this could make it easier to deploy management anti-patterns if one isn’t careful rather than align and negotiate with a win/win.

The win/lose proposition may yarner short term results at the expense of the long term. The win/win proposition ensures everyone’s value and validates their long term commitment to the vision. It’s more work, and it requires patience and skill, but it’s ultimately what sets apart, as Kevin would put it, the good deal makers from the bad deal makers.

Taking Kevin’s advice and applying it to ‘deals’ within an organization, may lead to the following:

• People might not get exactly what they want, or the exact terms they want, but they leave feeling good about the path forward knowing that their input was valued and that their input influenced the agreed upon direction
• Accountable decision makers leave feeling satisfied that they’ve come to a better decision knowing that everybody has been listened to. The initial approach may have changed due to taking the input from everybody and applying it to the ultimate decisions being made.
• Details of the approach were adjusted to give everybody more of what they want without compromising on the ultimate objectives.

Just like with Kevin’s deals, if everyone gets most of what they want, it makes for a smooth ride. A ‘deal’ that seems great for one party but is bad for another party isn’t going to work well – there will be a lot of friction when it comes to execution and all the baggage of human emotion that ultimately sabotage long term relationships and execution.

This article will walk through some key fundamentals that people can start to work through and introduce into their own work in order to better prepare themselves to move into architecture roles within their organization or outside of their organization.

Just doing your current job well may not be enough to propel you forward. It’s possible that your boss may recognize skills in you in addition to your expertise as a senior developer and may want to take a chance on moving you into an architecture role, but it’s not a good strategy. If you want something, you have to be pro-active. You have to “step up” (a wise person told me this once). You have to make things happen.

If there isn’t an ‘Architecture Practice’ in your organization, create one.

If your organization doesn’t have an architecture practice, there may be an opportunity to create it. You can become a pioneer at your organization by creating a (informal) team of highly skilled technical people focused on ‘architecture’ and use this to help push the organization to mature their architecture practices. If you don’t have SA’s or EA’s then you don’t have an existing architecture practice.

Here’s how you can push forward with new architecture ‘practices’ in both a formal or informal way. It may only require a few hours a month at first which will have a negligible impact on your day to day activities while opening the door to growing your architecture skills and the architecture maturity of the organization.

• Start new “architecture groups” and “architecture practices” within your organization. Invite technical people into the groups and facilitate discussions around creating an informal architecture practice. In the group, have regular meetings (bi-weekly or monthly to start) with brainstorming sessions and action items designed to move the architecture practice forward.
• Look to re-use components, identify standard patterns, and create technical reference architecture as a start. This could create a foundation on which to build out an architecture practice from the ground up, and who better to lead that practice than the ones who founded it at the ground floor and worked to build it out. Don’t worry about getting it perfect on the first pass; this is an iterative process.
• If the organization already has an existing practice, I wouldn’t recommend starting your own ‘architecture practices’ unless you also include some of the organizations existing architecture expertise. In this regard, you might want to focus on practices that are specific to your technical discipline that interest with the architecture practices of the organization.
• Personal Anecdote: I’ve found success in creating and participating in “architecture teams” within a large global organization that didn’t have an established architecture practice.

Express Your Desire to Move into an Architect Role

• Discuss this with your peers, with architects, and with your manager.
• Ask for feedback and be explicit about asking for more opportunity in the discipline as an architect.
• You are likely going to get positive and constructive feedback.
  • Personal Anecdote:  A long time ago, I did exactly this. From my perspective, I was already doing all of the things an architect should be doing. It turns out I was doing a lot of the things an architect should do, but not everything. My manager was frank with me and said “You are doing a great job, but when I look at architects in the enterprises I worked with in the past, they drive change to move the business forward.” Over time, I also went on to learn more about the strategic value of solution architects as it relates to expanding business value.

Amp Up Your Skills

• Negotiation, conflict resolution, emotional intelligence, and decision making are required. Practice this daily.
• Deepen your technical knowledge. Dive deeper into designing fault tolerant, high performance, high scale, geo-replicated, secure solutions.
• Increase your expertise about everything that intersects with technology and successful solution delivery, including, integration technology, DevOps, agile methodologies, CI/CD, etc

Certification Isn’t as Important as you Might Think It Is

• You don’t need TOGAF; I’d prefer to see people spend their time getting technical carts in their domain over TOGAF. Of all of the architects I’ve worked with, I have not noticed anything at an aggregate level that distinguishes a TOGAF certified architect from a non-TOGAF certified architect in terms of effectiveness in their role as an architect.
• You don’t need technical certs, but they can be useful to demonstrate particular expertise in a given technical domain. This expertise can also be demonstrated in other ways, including a portfolio of successful implementations given a particular technology, subject matter expert level of expertise demonstrated via mentoring, knowledge sharing, presenting, and being an evangelist for the technology, etc.
• Certs might help increase your technical knowledge which is great for development and very important for architecture, but remember these roles have a dependency on knowledge and not on certs.
• Think about the tens of thousands of people who hold coveted certifications in particular technology domains, but have little to zero practical experience in them.
• The phrase “if only I just had more certs” is a fallacy. Don’t fall for it.

Find a Mentor

• Look for architects in your organization that could mentor you in a formal or informal way, but make sure to find the right kind of mentor.
• Look for architects who are doing a great job overall and have garnered respect from their colleagues and peers and who are open to sharing their ideas and methods with you. Often these are the same people who are already completely transparent with their methodology and are already looking for ways to multiply the output of the people around them.
• Don’t just chose anyone to be your mentor; if you can’t find the right architect to mentor you, look outside of your organization instead. Ask people you know who might know a good fit within your extended network, and consider if you are following anyone on LinkedIn who may be a good fit as a mentor – and ask them.
• Personal Anecdote: Early on in my career, I remember working with an architect who was pretty closed. They didn’t like developers asking questions about their methods, and they didn’t want any transparency into their work (One of their responses might be: “You’re a developer, you shouldn’t be asking about or being involved in these conversations.”). Terrible attitude and needless to say, these are not the mentors you are looking for and likely won’t have the career progression that is worth emulating. I simply moved on and found other people to emulate and who worked well with other people.

Start Thinking Like an Architect

• Consider the architecture perspective of every technical challenge or piece of technical work presented to you.
  • As you aren’t actually an architect yet, you won’t have the title or the accountability. The issues with that is that it is others that will hold accountability; this may be your manager, another architect, or someone else in a more senior position than you. Because of this, it’s important that those who hold the accountability know what’s going on – over time they may (and should) empower you to make bigger decisions, but you’ll still need to align and work closely with them.
  • Developers like doing ‘fun things’ and sometimes that can lead to development for development’s sake (aka building out things which are fun for the developer, yet don’t always yield the highest business value given the effort and other priorities even though it keeps the developer busy). Try to avoid this kind of trap, and always focus only on building what delivers business value and be transparent about it.
  • Instead of rushing to build something – see what else exists.
  • Personal Anecdote: Before I became an architect, I was asked to build out a .NET based training application for one of the global divisions the company I worked for at the time had (develop the code, basically). At that time, and unbeknownst to that division, there was a company wide PeopleSoft training module that was just provisioned at the head office with the possibility of having other divisions using it. I was aware of it and helped get other divisions already on-board with it. I brought this to the attention of the IT manager of the division, and he was on-board with it and we moved forward with that PeopleSoft solution instead of building something net new.
    • This saved at least 3 months of work and allowed the division to on-board quickly.
    • They had no idea about this other initiative. This is a core tenant of what architecture does — find effective ways to meet the business need, don’t duplicate; re-use technology where appropriate. Drive change and drive the business forward.
    • If you think about it, how many developers would have taken on the initial development work and just did as they were asked? They might be the greatest developers at the company, and they’ll happily slave their days away for 3 months building the best darn training app known to exist because that’s what was asked of them. However, there is a huge hidden benefit that would not have been brought to the table by the developers who’d have happily slaved away building a new and amazing training app.
• If you want to be an architect you need to think like an architect thinks, and you need to be pro-active in driving change. Focus on the right things rather than succumbing to tunnel vision that prevents you from seeing beyond what you are presented with.

Good luck on your journey to becoming an architect. Additionally, take a look at a recent article I wrote Evaluating Solution Architect Competence – 10 Indicators which delves into the core competencies of Solution Architects. I also wrote Six Key Traits of Successful Solution Architect Consultants.