Understanding the Relationship Between the Product Owner, Solution Architect and Cloud Development-Deployment Teams

By John Conley

As organizations launch digital transformation projects using Agile and DevOps techniques, it’s easy for them to overlook the dynamic of the teams they assemble to make the transformation a reality. The transformation team needs a technical vision as well as a business vision. Without the clarity provided by the vision, the team can break down into a basket case of ineffective sprints and unproductive relationships. The Product Owner role helps drive that vision into a set of strategic initiatives that then are vetted and technically prioritized, with the help of the Solution Architect, into sprints. Of all the relationships on a given team, the most misunderstood perhaps is that of the Product Owner and the Solution Architect.
One of the reasons for this misunderstanding is that underestimate the complexity of a project. With smaller organizations, this may or may not be a big deal. But for larger corporations, especially those that are publicly traded, this is often inexcusable.
Within any organization, there are two figurative sandboxes that employees work in:
• The Business sandbox and
• The Technology sandbox
In the Business sandbox, employees carry out tasks that directly align with the organization’s marketing and business support operations. In the technology sandbox, employees are tasked with ensuring that the best and most updated technology is being used to support the Business sandbox. In a digital transformation, technology is no longer an afterthought, or “those IT nerds over there,” but an essential engine that drives the business forward. For every IT project, the leading voice of the business sandbox is the Product Owner (PO).
For the Technology sandbox, the Solution Architect (SA) is the main voice. The Product Owner, as the voice of the customer, internal employee, and executive stakeholder, has the responsibility to manage a Product Backlog of requests for new features to existing solution, brand new solutions, and bug/defect requests. Since the Product Owner is generally nontechnical (which is usually a good thing), the Enterprise Architecture team assigns a Solution Architect to that PO. The SA and PO meet regularly (usually weekly or biweekly) to go over the Product Backlog (PB) to vet each Product Backlog Item (PBI).
Depending on how large the PB is, the meeting can be either quick or tedious. The latter is especially true for larger organizations who are introducing the concept of a PB for the first time. Vetting a the PBIs in a backlog is a multistep process:

• PO Guesstimate
• SA Guesstimate
• PBI Priority Ranking
• Executive Budget Approval
• EA Backlog

PO Guesstimate
The PO t-shirt sizes (e.g., Small, Medium, Large) the business importance/impact of each PBI based on business strategies and capabilities being addressed. No technical input involved. Sometimes, the PO will recognize that a new PBI was already implemented in part or in full by another solution already in production, or is just a matter of training. In this case, the PBI can be marked “Resolved” or “Closed.” There will be times when the PO needs further clarification on the business rationale for a PBI from executive stakeholders. These can be marked as “Pending further business review” or something similar. These items should be time tracked so that they don’t age too long in the product backlog.
SA Guesstimate
After gaining business insight into the PBI, the SA t-shirt sizes the effort to analyze and implement technologically. No business input involved. The most popular t-shirt sizes used are Small, Medium and Large. Some teams use X Large for really big epics, but that’s up to you what works. Sometimes, the SA will recognize that a new PBI was already implemented in part or in full by another solution already in production, or is just a matter of training. In this case, the PBI can be marked “Resolved” or “Closed.” There are also times the SA may need a second pair of technical eyes to vet a PBI, so these should be marked “Needing further technical review.”

PBI Priority Ranking
If a PBI survives 1 and 2, then the business and technical rankings together should guide the PO and SA to prioritize the PBI relative to the others. Ranking PBIs is mostly subjective, but a good rule of thumb is to give weight to those items that are quick wins or have been heavily requested among users and executive stakeholders for some time.

Executive Budget Approval
Once the PBIs are prioritized, the PO gets budgetary approval of the top 10 (or whatever the threshold is) from executive stakeholders. Once a PBI is approved, the PO marks the PBI as “Ready for Implementation” or whatever status is agreed upon.

EA Backlog
There are different schools of thought regarding how to the technology team proceeds after a PBI has been approved. The Scaled Agile Framework offers some good ideas around value trains and solutions trains that have helped many organizations. Plain old Scrum, Agile and DevOps have good ideas here. Choose the approach that works for you. Here, I am focusing mostly on the pure process itself without getting bogged down in methodology wars. Once a PBI is approved, some technology leaders directly assign them to a sprint backlog. That might work for smaller organizations, but for larger ones, there is a need for a technology “brain trust” to determine the next step before it goes to any particular team’s sprint backlog. This is where Enterprise Architecture (EA) comes into play.
Often, SAs are under the direction of an EA Brain Trust who assigns them to one or more IT projects. So it would make since that there needs to be an EA Backlog the mediates between the PO’s Product Backlog and each team’s Sprint Backlog. This becomes especially true for organizations going through a digital transformation that involves implementing cloud computing. In the cloud, there are three layers that a PBI can intersect with:
• Software (SaaS)
• Platform (PaaS)
• Infrastructure (IaaS)
Each of these tiers would have a corresponding technology team of technical development and deployment specialists to implement the incoming PBI within the organizations IT environment. With the typical sprint backlog setup, the default assumption is that the incoming PBI is focused on developing software. But what if it only involves standing up a SQL database or a Linux or Windows Server VM? The determination about what kind of team to engage for the solution needs to be at the EA level. This technology brain trust, the EA Team, should have leaders from each area to help engage the right team. The PBI would then be routed to that respective team’s Sprint Backlog to work. The EA team would also do a more technical score of each incoming PBI to determine if an SA is needed to guide the sprint team. A good starting point for a scoring system is 1 to 50, where anything 26 or higher means the PBI is strategically important enough to warrant assigning an SA to the team. Less strategic PBIs can usually be handled by sprint teams with just a normal tech lead or dev lead. If an SA is needed, the SA would then work with the team to do normal sprint planning and backlog refinement activities. The SA creates necessary design docs that are within the guidelines of the master EA doc.

Considerations for Consulting Engagements
The same principles apply to a consulting practice engaging a prospective customer after making the initial sales pitch. After a consulting sales pitch, there has to be a customer assessment phase to determine the level of effort both parties can expect before a full engagement commitment is made. Both roles, PO and SA, are needed at a minimum to determine the effort. During the assessment, the PO and SA develop and manage a backlog of items the customer would need to address before committing to a digital transformation initiative. Depending on the size and complexity of the organization, this can take anywhere from a week or two, to several weeks or longer. The less mature the organization is technologically, the longer this assessment phase will take. It’s similar to when you hire house cleaning service. If it’s your first time, and your house is big, it will take longer than a similar house that already has regular house cleaning.

Wrapping Up
Hopefully this white paper helped in understanding the important relationship between a Product Owner and a Solution Architect. The former is business oriented and is the voice of the customer, employee user and executive stakeholder. The latter is technically oriented, and is the voice of the technology teams and the mediator between the functional requirements (usually user stories and other PBIs) and the nonfunctional requirements that the technology teams implement to satisfy the business. The EA team helps determine how to map incoming PBIs to the right technology teams, and will assign an SA if the PBI is architecturally and strategically significant.

About the Author
John Conley is a Dallas, TX, based Digital Solution Architect and Cloud Engineer Consultant. This is an excerpt from his forthcoming eBook “2020 Business Guide to Digital Transformation Governance.” Feel free to reach out to him if you have any questions or need consulting for your enterprise engagements.

By John Conley
Photo Credit: Mimi Thian from Unsplash.com

Note: This article is also available on Medium.com.

As organizations launch digital transformation projects using Agile and DevOps techniques, it’s easy for them to overlook the dynamic of the teams they assemble to make the transformation a reality. The transformation team needs a technical vision as well as a business vision. Without the clarity provided by the vision, the team can break down into a basket case of ineffective sprints and unproductive relationships. The Product Owner role helps drive that vision into a set of strategic initiatives that then are vetted and technically prioritized, with the help of the Solution Architect, into sprints. Of all the relationships on a given team, the most misunderstood perhaps is that of the Product Owner, the Solution Architect, and the developers and deployers who make the digital solution a reality.

One of the reasons for this misunderstanding is the underestimating of the complexity of a project. With smaller organizations, this may or may not be a big deal. But for larger corporations, especially those that are publicly traded, this is often inexcusable.

Within any organization, there are two figurative sandboxes that employees work in:

  • The Business sandbox and
  • The Technology sandbox

In the Business sandbox, employees carry out tasks that directly align with the organization’s marketing and business support operations. In the technology sandbox, employees are tasked with ensuring that the best and most updated technology is being used to support the Business sandbox. In a digital transformation, technology is no longer an afterthought, or “those IT nerds over there,” but an essential engine that drives the business forward. For every IT project, the leading voice of the business sandbox is the Product Owner (PO).

nesa-by-makers-IgUR1iX0mqM-unsplash
Photo: Nesa by Makers at Unsplash.com

For the Technology sandbox, the Solution Architect (SA) is the main voice. The Product Owner, as the voice of the customer, internal employee, and executive stakeholder, has the responsibility to manage a Product Backlog of requests for new features to existing solution, brand new solutions, and bug/defect requests. Since the Product Owner is generally nontechnical (which is usually a good thing), the Enterprise Architecture team assigns a Solution Architect to that PO. The SA and PO meet regularly (usually weekly or biweekly) to go over the Product Backlog (PB) to vet each Product Backlog Item (PBI).

Depending on how large the PB is, the meeting can be either quick or tedious. The latter is especially true for larger organizations who are introducing the concept of a PB for the first time. Vetting a the PBIs in a backlog is a multistep process:

  • PO Guesstimate
  • SA Guesstimate
  • PBI Priority Ranking
  • Executive Budget Approval
  • EA Backlog

PO Guesstimate

The PO t-shirt sizes (e.g., Small, Medium, Large) the business importance/impact of each PBI based on business strategies and capabilities being addressed. No technical input involved. Sometimes, the PO will recognize that a new PBI was already implemented in part or in full by another solution already in production, or is just a matter of training. In this case, the PBI can be marked “Resolved” or “Closed.” There will be times when the PO needs further clarification on the business rationale for a PBI from executive stakeholders. These can be marked as “Pending further business review” or something similar. These items should be time tracked so that they don’t age too long in the product backlog.

SA Guesstimate

After gaining business insight into the PBI, the SA t-shirt sizes the effort to analyze and implement technologically. No business input involved. The most popular t-shirt sizes used are Small, Medium and Large. Some teams use X Large for really big epics, but that’s up to you what works. Sometimes, the SA will recognize that a new PBI was already implemented in part or in full by another solution already in production, or is just a matter of training. In this case, the PBI can be marked “Resolved” or “Closed.” There are also times the SA may need a second pair of technical eyes to vet a PBI, so these should be marked “Needing further technical review.”

PBI Priority Ranking

If a PBI survives 1 and 2, then the business and technical rankings together should guide the PO and SA to prioritize the PBI relative to the others. Ranking PBIs is mostly subjective, but a good rule of thumb is to give weight to those items that are quick wins or have been heavily requested among users and executive stakeholders for some time.

Executive Budget Approval

Once the PBIs are prioritized, the PO gets budgetary approval of the top 10 (or whatever the threshold is) from executive stakeholders. Once a PBI is approved, the PO marks the PBI as “Ready for Implementation” or whatever status is agreed upon.

icons8-team-yTwXpLO5HAA-unsplash
Photo: Icons8 Team from Unsplash.com

EA Backlog

There are different schools of thought regarding how to the technology team proceeds after a PBI has been approved. The Scaled Agile Framework offers some good ideas around value trains and solutions trains that have helped many organizations. Plain old Scrum, Agile and DevOps have good ideas here. Choose the approach that works for you. Here, I am focusing mostly on the pure process itself without getting bogged down in methodology wars. Once a PBI is approved, some technology leaders directly assign them to a sprint backlog. That might work for smaller organizations, but for larger ones, there is a need for a technology “brain trust” to determine the next step before it goes to any particular team’s sprint backlog. This is where Enterprise Architecture (EA) comes into play.

Often, SAs are under the direction of an EA Brain Trust who assigns them to one or more IT projects. So it would make since that there needs to be an EA Backlog the mediates between the PO’s Product Backlog and each team’s Sprint Backlog. This becomes especially true for organizations going through a digital transformation that involves implementing cloud computing. In the cloud, there are three layers that a PBI can intersect with:

  • Software (SaaS)
  • Platform (PaaS)
  • Infrastructure (IaaS)

Each of these tiers would have a corresponding technology team of technical development and deployment specialists to implement the incoming PBI within the organizations IT environment. With the typical sprint backlog setup, the default assumption is that the incoming PBI is focused on developing software. But what if it only involves standing up a SQL database or a Linux or Windows Server VM? The determination about what kind of team to engage for the solution needs to be at the EA level. This technology brain trust, the EA Team, should have leaders from each area to help engage the right team.

The PBI would then be routed to that respective team’s Sprint Backlog to work. The EA team would also do a more technical score of each incoming PBI to determine if an SA is needed to guide the sprint team. A good starting point for a scoring system is 1 to 50, where anything 26 or higher means the PBI is strategically important enough to warrant assigning an SA to the team. Less strategic PBIs can usually be handled by sprint teams with just a normal tech lead or dev lead. If an SA is needed, the SA would then work with the team to do normal sprint planning and backlog refinement activities. The SA creates necessary design docs that are within the guidelines of the master EA doc.

Considerations for Consulting Engagements

The process of initiating a consulting engagement for a prospective customer has its own set of steps not unlike a software development project. After a consulting sales pitch, there has to be a customer assessment phase to determine the level of effort both parties can expect before a full engagement commitment is made. Both roles, PO and SA, are needed at a minimum to determine the effort.

During the assessment, the PO and SA develop and manage a backlog of items the customer would need to address before committing to a digital transformation initiative. Depending on the size and complexity of the organization, this assessment can take anywhere from a week or two, to several weeks or longer. The less mature the organization is technologically, the longer this assessment phase will take. It’s similar to when you hire house cleaning service. If it’s your first time, and your house is big, it will take longer than a similar house that already has regular house cleaning.

The successful completion of the engagement setup has, at a minimum, the following micro sprints as key milestones:

  • Request for info, quote, proposal from the prospective client
  • Sales pitch by the consultant
  • High level needs assessment by both the client and consultant
  • Service Level Agreement (SLA)
  • Product backlog creation and evolution based on user stories and other feature requirements

This set of milestones is by no means exhaustive but is meant to provide a set of guardrails to manage the micro sprints for the engagement setup process.

Wrapping Up

Hopefully this white paper helped in understanding the important relationship between a Product Owner and a Solution Architect. The former is business oriented and is the voice of the customer, employee user and executive stakeholder. The latter is technically oriented, and is the voice of the technology teams and the mediator between the functional requirements (usually user stories and other PBIs) and the nonfunctional requirements that the technology teams implement to satisfy the business. The EA team helps determine how to map incoming PBIs to the right technology teams, and will assign an SA if the PBI is architecturally and strategically significant.

About the Author

John Conley is a Dallas, TX, based Digital Solution Architect and Cloud Engineer Consultant. This is an excerpt from his forthcoming eBook “2020 Business Guide to Digital Transformation Governance.” Feel free to reach out to him if you have any questions or need consulting for your enterprise engagements.

How to avoid getting ripped off on website development

Every so often, I’ll come across someone who had bright eyed dreams about launching a website as part of their business plan, only to have those dreams go down in flames because someone they trusted with their hard earned money failed to deliver the desired website on time, if at all. The average losses they suffered in terms of websites that were half done or poorly done has been about $400-900. How could this happen?

The problem comes into play due in part to greed on behalf of the website developer, and lack of knowledge on the part of the customer. Usually, the potential customer asks friends for referrals to web developers or they post on the various social media sites looking for someone. Without doing much research, they pick a developer who sounds convincing and seems “technical.” The developer charges anywhere from $250 to over $1,000+ to do the whole website without providing a lot of details about what’s all involved. They usually pressure customers to pay the entire amount up front. A few customers try to negotiate a lower fee or pay half as a deposit, promising to pay the other half when the site is complete.

Regardless of what price is negotiated, the outcome is often the same: The developer starts on the site, putting up a web page or two, adding some photos and text, and few social media links here and there, and then poof! They vanish. The customer tries calling, but no answer or the number is disconnected. Hundreds of their hard earned dollars gone and they’re ready to sue.

But wait. Is there anything you could have done differently to avoid losing so much money?

Yes! The first step is to make sure you have a reasonable business plan to go along with your website. Surprisingly, most website customers downplay this step, thinking all they have to do is upload a few photos and a contact page with an about page explaining what they offer, and that’s it. No! Your website is a reflection of the business processes you want your customers to be able to do using your website.

For instance, if you are a hair stylist, you may want customers to book appointments, look up and select various hair styles, order hair, manage the way they pay you, allow customer reviews, etc. By not outlining these features up front, you increase the likelihood of misunderstandings between yourself and your website developer. This, then, leads to you feeling like the website is not complete, and the developer might get frustrated and walk off. This is not to say that there are no bad website developers (there are), but in this specific scenario, failure to describe the features of your website along business processes will increase the likelihood of misunderstanding.

Second, research potential website developers. Remember you get what you pay for, so if someone is offering to do your site for a ridiculously low amount (like under $100 total for a full website), chances are it might be a bait and switch scam. Three to five years’ experience should be minimum for the best quality service, although that’s not to say anyone with less experience would be that bad. But it takes some years to get into a rhythm in website development. My company, Samsona Software, has been around since 1993, so I know something about longevity and consistent customer service.

Finally, know that there is a difference between a website designer and a developer. Designers are usually focused on creating web pages and making them look good from a visual appeal standpoint. Website developers go deeper than that:

  1. Hooking up your pages to databases
  2. Integrating with cloud computing platforms such as AWS and Azure
  3. Integrating with eCommerce platforms like Shopify, Magento and BigCommerce
  4. Implementing microservices to harness the power of various business features unique to your industry. This latter one is part of my offering to my larger business customers.

If you get a chance, try an initial consultation first before seeking help building your website. I can help with that, or anyone with serious experience in this space can do an initial consultation to help you get to where you want your business dreams to take you.

About the Author

John Conley is a technology and digital transformation consultant for Samsona Software Co, Inc., based in Dallas, TX. His service offering is focused on enterprise and solution architecture, as well as small business solutions. Feel free to contact him for your business technology needs.

The Idea of Business Enabling Microservices

a human user has a certain business objective that the microservice must fulfill, and that microservice needs a dedicated data store to manage the critical business data it needs to satisfy the user.

As digital transformation sweeps the business landscape, executives and managers are rethinking their business processes. This paradigm shift is important because technology is the lifeblood of industry, the economy and even society at large. People are becoming more comfortable living their personal and business lives primarily through mobile devices, laptops as well, and less so on traditional desktop PCs. Wearable technology, a relatively smaller niche in the overall ecosystem, will eventually compete with today’s mobile devices for digital hegemony among users. But what will be common among all of these ways of conducting business through technology is the need to design components to automate business processes.

As of today, these components are usually realized as microservices in the cloud.

I’ll avoid getting too technical about microservices. Just know that microservices are atomic processes that work together to provide a business solution to a business problem. What that means is that each business process, when well defined, is kinda like a worker just like any other human. Of course, a microservice is very limited to its prescribed business task, minus the distractions that we humans have in our personal lives.

How might this automated worker be visualized for the busy executive to understand? Imagine a bank that offers three account products to the public:

 

1.       Savings Maximizer

2.       Checking Plus

3.       Secure Safe Deposit Box

 

Many years ago, in the age before modern automation, the bank would hire specialists in each of these products to manually offer and maintain these kinds of accounts. The workers would use what was called “ticklers” (like paper ledgers) to keep track of account info. With advances in software technology, managing such banking products became more automated. But in their simplest forms, how might we come up with software components for these products? Figure 1 shows one possibility.

microservice 1

Though the three services look cute in blue against a white background, they can’t sit in isolation. They must do something meaningful to deliver real business value in a way that enables executives and managers to then manage the impacted value chain. In a nutshell, our microservices must do the following:

 

1.       Get data from or display data to the user (knowledge worker, the primary persona)

2.       Execute a workflow on behalf of a user

3.       Get data from or save data to the on prem or cloud database/data lake

In other words, a human user has a certain business objective that the microservice must fulfill, and that microservice needs a dedicated data store to manage the critical business data it needs to satisfy the user. Figure 2 shows the end to end context that supports this flow of business data from the user to the data store.

microservice 2

Ok now that’s a little better. The microservices have end to end context, with the users on the left and the solution tiers to the left. The users only know about the bank app, which governs their user experience (UX). From a business perspective, it would be important to hire technology partners who can pair the UX requirements with the technical plumbing to identify and locate the right microservice for the given user story.

Notice that each microservice has a link to their own databases. This is a fundamentally important part of microservice design that allows the independence of business components, making ongoing development and maintenance cost effective for your organization. If a database goes down for whatever reason, the bank app still have access to the active databases without impacting the user experience.

What’s missing is the fact that each of the microservices can communicate with each other directly (usually by JSON messages) without need to directly access each other’s databases. Also absent is the fact that microservices are usually deployed in the cloud in containers, which encapsulates much of the platform configurations needed to keep the component independently maintainable from a system maintenance standpoint. These cost savings positively impacts the bottom line of the each business product, allowing your organization to in turn pass the savings on to your customers, giving you a competitive advantage. Hopefully as an executive sponsor or manager, you can begin to incorporate microservice thinking into your overall digital transformation strategy.

 

About the Author

John Conley is a digital transformation consultant for Samsona Software Co, Inc., based in Dallas, TX. His service offering is focused on enterprise and solution architecture, as well as . Feel free to contact him for your business technology needs.