Co-Publishers: Niel Meyer, VP of Application Delivery, Express and TheoremOne
COVID-19 has brought about unprecedented disruption in the economy resulting in drastic changes to business strategies, especially within the apparel retail industry. We now need to refocus our attention to accommodate new requirements like social distancing. We all know that change is inevitable and this pandemic has introduced another component: the rate at which change is required.
So, what have we learned from the experience of going through this pandemic? We have learned that we have focused on the “how” rather than the “what” over the past decade. We have introduced concepts like bimodal development, agile development and continuous integration, and continuous deployment. These concepts introduced different software delivery approaches focused on “how” we can deploy technology solutions more effectively. However, we now have to look at “what” technologies to deploy in a very different way.
With the announcements of many retail store closures in March, apparel retailers had to review all capital investments with a completely different lens. Cash flow needed to be conserved as revenues were drastically reduced, in some cases limited to eCommerce sales. The only prioritized projects were ones that supported eCommerce or new business capabilities like buying online pick up in-store (BOPIS) or curbside pickup that would enable stores to re-open and allow for social distancing. If we knew last year, what we know now, how would we have approached our annual planning cycle? How can we change our planning cycle to be much more responsive to “what” technology solutions to deliver in an ever-changing retail environment?
“What” technology solutions to deliver has two components to it, selection and prioritization. The first component focuses on our ability as technologists to identify technology solutions that support the business strategy. This is certainly not a new concept, but the pandemic has challenged our approach. Suppose we just focus on the business strategy in an ever-changing environment. In that case, we will continue to find ourselves in a situation where it is very challenging to pivot, and we have learned that “pivot is the new plan.” To overcome the constant shifts, we need to focus on the business capabilities that support the overall business strategy.
A business capability is the intersection of a business request, based upon an understanding of the underlying business process, with a technology solution. Suppose you can map a new business request to your business capabilities. In that case, it enables you to understand what changes are required for a business process when proposing a new technology solution. It can be leveraged as the translation layer or mapping table between business and IT. The need for this capabilities mapping is accentuated when you are required to pivot more frequently. This describes the role of a Business Architect. Wikipedia defines Business Architecture as “a discipline that represents holistic, multidimensional business views of capabilities, end-to-end value delivery, information, and organizational structure; and the relationship among these business views and strategies, products, policies, initiatives, and stakeholders.”
The capabilities mapping alone will, however, not solve all our problems. It is an essential component but needs to be supported by some additional elements of what we would traditionally describe as Enterprise Architecture. Gartner defines Enterprise Architecture as “a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change towards desired business vision and outcomes. Enterprise Architecture delivers value by presenting signature-ready recommendations for adjusting policies and projects to achieve targeted business outcomes that capitalize on relevant business disruptions”.
Enterprise Architecture typically has a 30,000-foot view of all of the technology infrastructure within the organization. See them as Air Traffic Control for technology. They guide aircraft (technology projects) through controlled airspace (technology landscape) using a set of traffic separation rules. I do not want to get hung up by the definition of Enterprise Architecture but would instead want to look at some of the key deliverables that we should focus on to assist us in reacting to fast-changing priorities as we experienced with this pandemic. One key deliverable of Enterprise Architecture is to define a set of guiding principles or guardrails to be considered with each new technology solution proposal.
Architectural standards certainly have their place within the IT department. Still, to bring Enterprise Architecture to life for the business, especially for the business executives who will be approving the investment for your architectural proposals, you need to define some practical Enterprise Architecture principles. I would advise limiting the actual number of principals to as little as possible. Consider defining no more than 5 to 7 principals. Whenever you evaluate new technology or prepare an architectural proposal, you need to measure the proposal against these principals. Let me give you an example of a proposed Enterprise Architectural principal in order to explain.
Maximize reuse: Enable new business capabilities by designing reusable, extendable, and scalable solutions. This would be a good principal whether your goal is to reduce development cost and time by leveraging investments in existing on-premise technology stacks or to reduce the complexity of your integrations with a cloud-based solution using micro-services. The point is, you define 5 to 7 principles, which you then use as guardrails for selecting software solutions to deliver new or enhanced business capabilities, similarly to how Air Traffic Control uses traffic separation rules to operate aircraft safely.
The role of the Solution Architect is to design and select the right technology solution. According to AltexSoft, Solution Architecture consists of “the practice of designing, describing, and managing the solution engineering in relation to specific business problems.” It is very similar to the pilot in command, who is ultimately responsible for landing the plane once he receives the flight plan from Air Traffic Control. Similarly, the Solutions Architect receives the architectural proposal from the Enterprise Architecture team and then creates the technical design implemented by the development teams.
There has been a lot of debate about whether this role is part of a centralized Enterprise Architecture team or whether it should be embedded in the different Technology teams. There is no right or wrong answer as it all depends on the organization’s size, the industry, and the complexity of the technology landscape as both options have definite pros and cons. The bottom line is that this is an important role that allows the organization to pivot when encountering unexpected disruptions quickly. Use the example of some States only opening for curbside deliveries during the COVID-19 lockdown. With Enterprise and Solutions Architects in place, it would have been possible to quickly estimate and design the changes required in order to support the newly required business capability without interrupting other inflight projects.
Now let’s look at the second component of “what” technology solutions to implement, namely prioritization. Prioritization goes hand in hand with the first component of selection, and I believe neither can be implemented successfully without the other. Even though this is not a new concept, some new challenges have been introduced with the pandemic. Let’s stick to the aviation analogy and call this the onboarding process. This includes all the different steps for an aircraft to successfully and safely complete a flight. Similarly, there are several steps required to progress from a request for a new or enhanced business capability to the proposed technical solution’s actual successful implementation
I am deliberately calling this onboarding in order not to confuse it with the project intake process. Several activities have to be considered even before you can determine when a new business request should even become a project. A great example is the initial effort estimation. A lot of effort goes into estimating new requests, which are not always considered when we plan resource availability in our development teams. The result of this is that we either delay project delivery as we pull off resources to perform the estimation for new business requests, or we have a large backlog of new business requests that simply does not get through the estimation process. This can have grave financial ramifications if we consider how quickly we needed to pivot and consider delivering new business capabilities like a curbside pickup.
Step 1: Business Request
The first step in the onboarding process is to understand and document the ask of the business. The Business Architect plays an important role here to translate the ask of the company from a business process view to a business capability view that can then be translated into a documented business request. I am deliberately not calling it a business requirements document (BRD) as this should be an abbreviated version of the business requirements document as we have not yet decided whether this request will become a project. The business request should have just enough information to perform an initial estimate, which brings us to the second step.
Step 2: Initial Estimate
The natural second step of the intake process would be to perform the initial estimate to get a sense of the size or order of magnitude of the business request created in the first step. This can be achieved through T-shirt sizing, which is a relative measure based on similar business requests completed in the past. The amount of time spent on the initial estimate depends on the number of technology resources available to perform the forecast and the preferred accuracy level. Bear in mind that this step’s primary purpose is not to get final investment approval but to simply perform an initial estimate based on the proposed technology solution to size and prioritize the request. The technology solution should be presented by the Enterprise Architecture team, taking the principles/guardrails into account. This will ensure the consistency and scalability of the different technology solutions across the application development teams. Suppose the Enterprise Architecture team is small, or the business request only pertains to one application development team. In that case, the Solutions Architects can also be engaged to perform the initial estimation.
Step 3: Prioritization
The third step is prioritizing and getting alignment on which of the new business requests should move to the next step. This is a critical step as you do not want to invest many hours in estimating new requests that might not necessarily come to life as a project. Most organizations have some governance structure that approves the capital investment on Technology projects. That same governance body can also be tasked with reviewing all new business requests for approval to move to the next step. This should not increase their existing workload; it is just a gate, much like the document check at the boarding gate, to ensure that we only allow passengers with the required documentation to board the plane. This will ensure that we only proceed with detailed estimates on business requests that deliver new or enhanced business capabilities that align with the overall business strategy.
Step 4: Detailed Business Requirements
Once approved to proceed, the business request is handed over to a business analyst who then expands the business request into a detailed business requirements document with the business partners’ support. Upon completion, the business requirements document is handed off to the Solutions Architect, who will then complete the design and detailed estimate based on the business requirements document and the technology solution proposed by Enterprise Architecture. To complete the fourth step, it will be necessary to quantify the business benefit. This will allow for the calculation of financial metrics like return on investment (ROI) and payback period required to get back in front of the governance body for the approval to proceed with the financial investment. This step compares to the pilot in command requesting Air Traffic Controls permission to proceed to the runway.
Step 5: Project Execution
In the fifth and final step, the business request has now become a project. Much like weeks of planning a vacation resulting in the announcement: “We have completed our boarding, please make sure that your seat backs and tray tables are in the upright position and that your seatbelt is correctly fastened…” The project manager is assigned, and the project is officially kicked off. The project now moves through normal execution, whether waterfall or agile. During the project’s execution, the Solutions Architect refers back to the original technology proposal to ensure that the design remains in line with the original request. It is sometimes necessary for the Solutions Architect to deviate from the original technology proposal due to unforeseen external factors like a pandemic, much like the pilot in command deviating from the original flight path due to unplanned external factors like malfunctioning landing gear.
Speaking of landing the plane…
We should take the learnings from this pandemic and its impact on our technology delivery and use it to ensure that we are ready to pivot, whether it be due to a second wave or to create a competitive advantage through a disruptive new business capability. We can achieve this by focusing on the “what” through using both Enterprise and Solutions Architecture to select the right technology solutions and then prioritizing it through the five steps of a clearly defined onboarding process.
This is what Air Traffic Control, a Pandemic, and Technology have in common!
