How to Pick the Right Number of IT Cloud Team Members

On Medium and Substack

Coming up with a healthy, balanced ratio of the number of team members to number of clients is still a relatively subjective exercise. Not quite scientific yet. There are rules of thumb out there to start with, but it ultimately comes down to your requirements and the size of your B2B clients and B2C customer base. Also, the amount of request for new features or bug fixes spawns customer telemetry data that will factor into the ratio.

The following provides a rule of thumb starting point for your fine tuning needs based on personal observation in a consulting professional capacity over many years:

·         Solution Architects: 1 for every set of 4 or 5 typical quarterly release projects or B2C clients

·         Database Team: 1 to 5

·         Networking Team: 1 to 5

·         OS Sys Admin Team: 1 to 7

·         Monitoring Team: 1 to 3

·         Security: 1 to 5

·         R&D: 1 to 10

Continuously capturing and tracking team role and skill inventory will help in determining these ratios, calibrating them over time.

Example Cloud Team Structure: Monitoring and Alerting

How many cloud monitoring team members do you need to support B2B corporate clients?

The number of cloud monitoring team members required to support B2B corporate clients can vary widely depending on the size and complexity of the clients, the scope of the services being offered, and the level of support required by the clients. However, some factors that can help determine the appropriate staffing levels for a cloud monitoring team might include:

1.       Number and size of clients: The more clients you have and the larger their businesses are, the more team members you will likely need to support them effectively.

2.       Service scope: The more services you offer and the more complex they are, the more team members you may need to monitor and maintain them.

3.       Client service level agreements (SLAs): If your clients have SLAs that require a high level of service availability and response times, you may need more team members to meet these requirements.

4.       Automated vs. manual monitoring: The more automated your monitoring is, the fewer team members you may need to support your clients.

With these factors in mind, a typical cloud monitoring team for a B2B corporate client might include anywhere from 5 to 15 team members, depending on the size and complexity of the clients being served. This team might include roles such as:

1.       Cloud monitoring manager or team lead

2.       Cloud monitoring engineers or technicians

3.       Customer support specialists

4.       Product Managers/Owners, Project managers or coordinators

Hope this helps give your sprint planning a starting point. Determining the optimal staffing levels for a cloud monitoring team relies on various factors that are unique to your organization and clients. I recommend you thoroughly evaluate your clients’ needs, including number of users and groups, and the level of assistance necessary to guarantee that you have the right staffing levels to deliver dependable and excellent services.

Introduction to Optimizing Cloud Team Structures for Continuous Product Improvement

Editor’s Note: Also featured on Medium, LinkedIn and Substack

Since 2020, many organizations launched digital transformation initiatives to automate their processes and adopt or migrate their technology operations to the cloud. Surveys by large analytics organizations such as McKinsey and Gartner have suggested that most have failed for a variety of reasons.

It is difficult to provide a precise number of failed initiatives as there are no publicly available statistics on the number of digital transformations that have fallen short in corporations since 2020. However, it is generally accepted that the success rate of digital transformation initiatives is not particularly high, with various surveys and reports suggesting failure rates ranging from 60% to 84%.

There are several reasons why digital transformation initiatives can fail, including a lack of clear executive strategy and leadership, inadequate investment in technology and talent (including cloud team structures and staffing mix), resistance to change from employees and customers, and a failure to align digital transformation efforts with business goals and complex customer needs.

It is worth noting that the COVID-19 pandemic has both accelerated the need for digital transformation in many organizations and created new challenges for digital transformation initiatives. Many organizations have had to adapt quickly to new ways of working and engaging with customers, which has put additional pressure on digital transformation initiatives. This has led to an underestimating of complexity of cloud team structures which are needed for a continuous product improvement process that leads to high Quality of Service (QoS) for customers.

In any case, it is clear that digital transformation is a complex and challenging process that requires careful planning, execution, and ongoing adaptation to changing circumstances. While some digital transformation initiatives may fail, it is important for organizations to learn from these experiences and continue to pursue digital transformation in order to remain competitive in today’s fast-paced, digital-first business environment.

The implication is that optimizing the structure and staffing of an IT cloud team can be a challenging, often complex process. There are a few key considerations that executive leadership and upper management can take into account to make the most of their staffing resources:

· Define clear cloud teams, roles and responsibilities

· Determine the necessary skill sets

· Consider the size and complexity of the cloud environment

· Balance in-house and outsourced resources

· Foster a culture of continuous learning, research and development

Define clear cloud teams, roles and responsibilities

The establishment of precise roles and responsibilities within a cloud team is an integral component of accomplishing organizational objectives. This facilitates the comprehension of individual responsibilities, enabling team members to better grasp the impact of their contributions towards the overarching organizational vision. In other words, they see the direct value of their sprint team contributions to solving customer problems. This methodology also serves to remove redundancies and channel the team’s efforts towards areas of high importance. Further, it is imperative to ensure sufficient staffing levels in each role to guarantee optimal customer service delivery.

The monitoring team, for instance, can be staffed adequately to proactively identify and troubleshoot customer problems before the customer discovers them. In the case of large organizations, the establishment of a personnel-to-client, product, or project ratio is a judicious decision to ensure the effective allocation of resources. Aligning team member counts to project ratios helps to provide good coverage to the number of clients and customers your organization has. This is especially important for B2B client scenarios, where having one or two developers may not be enough for 20 large B2B clients, each with millions of users.

Determine the necessary skill sets

For any given cloud or digital transformation project, there are certain skills need that must align with user requirements with emphasis on scaling the number of skilled workers with the size of the customer (B2B) or customer base (B2C). It is essential to identify the highly specialized skill sets required to support cloud infrastructure, including proficiencies in:

· distinct cloud platforms (SaaS, PaaS, IaaS)

· programming languages, and

· security protocols

This strategy aids in directing recruitment and training endeavors and guarantees that the team possesses the appropriate blend of expertise.

Consider the size and complexity of the cloud environment

The magnitude and intricacy of the cloud environment can significantly affect the personnel requirements of the team. A diminutive and less intricate environment may demand a modest team, while a vast and multifaceted environment may necessitate multiple and more specialized teams.

Let’s unpack this a bit. Assume that a company is using a public cloud service provider (CSP) for their operations. They have established a dedicated cloud monitoring team to oversee and manage their cloud infrastructure. In this scenario, the size and complexity of the company’s cloud environment would be the primary determinants of the necessary staffing levels for the monitoring team. Some organizations ignore this critical factor to their detriment, which is often where cloud migrations and digital transformations fail.

For a smaller cloud environment with limited cloud resources and services, the monitoring team may comprise a few personnel with a general understanding of cloud infrastructure and basic monitoring tools. The small mom and pop IT shops won’t be dealing with several major B2B clients or millions of users in their customer base. On the other hand, a larger and more complex cloud environment, with multiple cloud services and resources, may require a more extensive monitoring team with highly specialized roles, such as cloud security specialists, network monitoring experts, cloud architecture professionals, and data analysts.

In this way, the staffing requirements of the cloud monitoring team would depend on the size and complexity of the cloud environment, and the necessary skill sets for the team members would be based on the specific cloud services and resources being utilized.

Balance in-house and outsourced resources

It is crucial to identify the most advantageous equilibrium between in-house/onshore and outsourced/offshore resources. This could involve utilizing third-party vendors for particular functions, such as cloud security, while maintaining essential development and maintenance tasks in-house. For instance, cloud monitoring and alerting might require 24/7 operation with coverage in various regional time zones, necessitating multiregional team coverage.

Determining the optimal balance between in-house/onshore and outsourced/offshore resources can have several cost advantages and disadvantages for an organization. One of the primary cost advantages of outsourcing is the potential for reduced labor costs. Outsourcing to offshore locations may allow companies to benefit from lower labor costs in countries with lower wage rates, thus reducing overall operational expenses. Additionally, outsourcing specific functions, such as cloud security or data entry, may be more cost-effective than hiring in-house staff with the same expertise.

On the other hand, outsourcing may have a few drawbacks. For instance, communication issues may arise due to language/cultural barriers or time zone differences, which may impact project timelines and increase costs. Time zone difference can be a big factor in managing quality of service (QoS) for customer service level agreements. Monitoring and alerting, for instance, can be rendered useless if a major B2B client in the Central Time zone has to wait for Level 1 or Level 2 support in an Asian time zone. There may also be additional costs associated with managing the outsourced team, such as oversight and coordination expenses. Additionally, outsourcing may reduce the level of control and oversight that an organization has over its operations and data, potentially leading to security risks.

Maintaining in-house staff can be advantageous in terms of control and flexibility. An in-house team is typically easier to manage and can respond more quickly to changing business needs. Additionally, it can be easier to ensure the quality of work when it is done in-house. However, in-house staffing may also be more expensive than outsourcing, as it requires investing in hiring, training, and retaining staff with specialized skills and knowledge.

Ultimately, the most cost-effective approach will depend on various factors, including the size and complexity of the organization’s operations, the expertise required for specific functions, and the cost of labor in different regions. Therefore, it is essential to carefully weigh the advantages and disadvantages of each approach and determine the most effective strategy for the organization.

Foster a culture of continuous learning, research and development

Cloud technology is constantly evolving, so it’s important for the team to stay up-to-date with the latest developments and trends. Management can foster a culture of continuous learning by providing access to training and development opportunities and encouraging team members to stay current with industry developments. Having an R&D team, in association with a corporate training team, can ensure that the organization is discovering new technologies that can improve team productivity. The training team can continuously plan and coordinate training for new technologies.

Conclusion

In conclusion, there are certain strategies management can plan and implement to optimize the structure and staffing of their IT cloud team, ensuring that it is well-positioned to support the organization’s strategic objectives. The process of digital transformation is a challenging and intricate journey that necessitates meticulous planning, implementation, and continuous adaptation to dynamic conditions.

While a number of organizations may experience setbacks during their digital transformation (DT) initiatives, it is crucial to derive lessons from these experiences and pursue DT to remain competitive in the rapidly evolving, digital first business world. Industrial era management strategies are obsolete. Optimizing the structure and staffing of an IT cloud team while transitioning from the industrial mindset can also be a complex process.

As such, there are key considerations that executive leadership and upper management can take into account to maximize their technical staffing resources. By adopting a strategic and comprehensive approach to staffing, organizations can leverage the benefits of cloud technologies and improve their business outcomes.

Digital Agile Strategies: When the Sales, Product and Sprint Teams Work in Tandem

The way a company makes money is by selling products and services to the public. Without sales, no revenue comes in. Revenue, and especially profits, are the lifeblood of an organization. Cut that off, and the company dies. Therefore, the sales staff must constantly sell, sell, sell at all costs to keep the company alive. It’s really that cut and dry.

Or is it?

Side note: This article also appears on Medium.com

True, the sales team is like the priesthood of capitalism that keeps the company’s future alive by sacrificing itself regularly. They should be applauded for this effort. But there is a limit on how much capacity the product team has to support a highly aggressive sales team. If you’ve been in technology long enough, even beyond IT, you know the delicate balancing act between aggressive sales on one hand, vs aggressive timelines to push out quality products based on features in the product backlog and tasks in the sprint backlog.

Product teams are caught in the pinch between the successful sales team, and the quality driven sprint team. If the sales team is too aggressive, product quality may suffer. If, on the other hand, sprint teams are behind schedule, the product team risks losing a sale that cuts the sales team commissions. Both of these scenarios can result in reputational damage as potential customers can get frustrated, terminate any sales agreements, and buy from a competitor.

Balancing the motives and goals of the sales, product and sprint teams is never an easy exercise as business forces can change dynamics rapidly. However, despite the temptation to revert back to ego driven knee jerk reactions to business events, it is crucial for

1. The sales team to be in alignment with the agile product team to ensure that the product quality meets customer expectations
2. The product team to be in alignment with the agile sprint team for the same reason

Aligning Sales and Product Teams

The following graphic highlights some strategies the sales and product teams can implement to ensure that product quality meets customer expectations:

Collaborate on product requirements

Working closely together at the sales and product team level improves the chances that customer requirements are well understood and documented. The sales team can provide valuable insights into the customers’ pain points, preferences, and expectations, which in turn can be used to prioritize quarterly product features and enhancements.

Attend sprint demos

The sales team should attend sprint demos to witness firsthand the progress made by the product team. They can also provide real-world feedback on how well the product is aligning with customer needs. This will allow the sales team to have some visibility into the product development process, as well as help identify any gaps or areas that need improvement.

Provide customer feedback

The sales team should be the primary source of customer feedback and possibly user story input for the product team. They should provide surveys or plain text feedback on customer satisfaction, feature requests (hopefully in the form of user stories), and pain points to help the product team adjust priorities and make product improvements.

Attend retrospectives

Some product teams may hesitate to invite the sales team to retrospectives, but there is some value at times in doing so. The sales team, once it understands the nature and importance of this exercise, should attend retrospectives to provide feedback on the product development process and collaborate with the product team to identify areas for improvement. This will help the product team to continuously improve the quality of the product and ensure it meets customer expectations.

Develop a shared understanding of quality

The sales team and product team should develop a common understanding of what constitutes high-quality products. This shared understanding should include customer expectations, usability, and performance metrics, among others.

In summary, by collaborating on product requirements, attending sprint demos and retrospectives, providing customer feedback, and developing a shared understanding of quality, the sales team can align with the agile product team to ensure that product quality meets customer expectations.

Aligning Product and Sprint Teams

Continuing, the chain of collaboration between the sales and product teams extend to the collaboration between the product and sprint teams. To maintain product quality, the product team must be in alignment with the agile sprint team continuously. A few ways the product team can align with the agile sprint team to achieve continuity include:

Collaborate on sprint goals

The product team should work closely with the sprint team to define sprint goals that are aligned with the product roadmap and customer needs. By setting clear goals, both teams can ensure that the work being done during the sprint is focused and contributes to maintaining product quality.

Define acceptance criteria

The product team should define acceptance criteria for each user story or feature being developed during the sprint. The acceptance criteria should outline the conditions that must be met before a user story or feature is considered complete and of acceptable quality. This ensures that everyone on the sprint team understands what is required to deliver a quality product.

Conduct high level code reviews

The product team should participate in code reviews, with the guidance of the solution architect assigned to the product backlog or at least the most senior technical leader of the sprint team. This approach is a best practice, helping to make sure the code being developed during the sprint meets the product team’s quality standards. This can include reviewing code for readability, maintainability, and adherence to coding standards.

Provide effective feedback and business guidance

The product team should provide feedback and guidance to the sprint team throughout the sprint. This can include reviewing and providing feedback on user stories, features, and design decisions, as well as providing guidance on how to address any quality issues that arise during development.

Collaborate in sprint reviews and retrospectives

The product team should participate in sprint reviews and retrospectives to provide feedback on the quality of the product and the development process. This will help identify areas for improvement and enable the team to continuously improve the quality of the product.

By collaborating on sprint goals, defining acceptance criteria, conducting code reviews, providing feedback and guidance, and participating in sprint reviews and retrospectives, the product team can align with the agile sprint team to maintain product quality. As a result, the emphasis on optimal quality will ensure that the product meets customer needs and expectations while adhering to high quality standards.

How agile sprint planning and sprint retrospectives can improve crucial conversations

Agile sprint planning and sprint retrospectives can improve crucial conversations between C-level executives, product managers, and sprint teams in several ways:

1. Encourages collaboration
2. Creates transparency
3. Facilitates alignment
4. Encourages continuous improvement

Collaboration

Agile sprint planning and sprint retrospectives are collaborative processes that involve input from all stakeholders, including C-level executives, product managers, and sprint teams. This might be surprising for some agile practitioners, but sprint planning and retrospectives are actually important business process in the digital era. In working together, they can gain a deeper understanding of each other’s perspectives, identify potential roadblocks, and find solutions to address them.

Transparency

Agile sprint planning and sprint retrospectives together promote transparency by providing regular updates on the progress of the project. Providing continuous updates can help C-level executives and product managers gain insight into the sprint development process, and identify areas where they can provide support or resources. The basis for C-level support of the team is what can be the basis of what’s called “technical empathy.”

Alignment

Agile sprint planning and sprint retrospectives help align the goals and priorities of all stakeholders involved in the project. By having a shared understanding of the project’s objectives and progress, C-level executives, product managers, and sprint teams can work together more effectively towards a common goal.

Continuous Improvement

Agile sprint planning and sprint retrospectives provide opportunities for continuous improvement. During the sprint retrospective, the sprint team reflects on what worked well, followed by what didn’t. The team then identifies areas for improvement. This crucial feedback can help C-level executives and product managers understand the team’s needs, as well as identify ways to support the team in achieving their goals.

Conclusion

The product team finds themselves caught between the competing interests of the successful sales team and the quality-driven sprint team. If the sales team is too aggressive, it could lead to a decrease in product quality. Conversely, if the sprint teams fall behind schedule, the product team risks losing a sale, which in turn could reduce the commissions of the sales team. In both scenarios, the company’s reputation may suffer as frustrated customers could terminate sales agreements and turn to competitors.

Maintaining a balance between the objectives and goals of the sales, product, and sprint teams can be a challenging task as market forces can change rapidly. Despite the temptation to react impulsively to business events, it is crucial for:

1. The sales team to work in concert with the agile product team to ensure that the product quality meets customer expectations
2. The product team to collaborate with the agile sprint team to achieve the same goal.

Generally speaking, both agile sprint planning and sprint retrospectives create a collaborative and transparent environment that fosters (1) open communication and (2) continuous improvement. Avoiding breaks in collaboration keeps the sprint team alert and ready to respond to business events. By encouraging crucial conversations between C-level executives, product managers, and sprint teams, an organization can help ensure that each member of each team is working towards the same goals and priorities, which is not exactly an easy proposition in an ever changing digital world. At the end of the day, the project is has to be successful in meeting customer needs and business objectives for the given product.

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

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).

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.

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 Properly Plan Your Website Before Launching It

 

The importance of knowing your business processes before hiring a web developer is essential. Documenting the steps you take to engage your customers, suppliers, employees, investors, lenders and government agencies are important. This means you have to properly plan every step of the way from where you are now, to where you want to be. You have to answer questions like:

1.       How do I reach out to the public to convince them to become paying customers?

2.       How do I want my customers to learn more about my business?

3.       How can customers read about my products or services before buying?

4.       How can I convince customers to make the buy decision?

5.       How can I make it convenient for customers to pay for my products and services?

6.       How easy is it for my customers to understand my refund policy and actually request a refund?

7.       How can I work with my suppliers to make it easy to buy their products and services I need for my business?

8.       How easy is it to resolve my customers’ refunds when I need to get reimbursed from suppliers? Do my vendors make it easy for me to get such refunds?

9.       How will my business continue if a disaster happens or if a supplier I rely on goes out of business?

10.   How do I get the necessary licenses for my business from the local government agency (if required)?

11.   How do I pay my business sales and income taxes online?

12.   If I have employees:

a.       How do I manage my workers HR and payroll needs?

b.       How do I make it easy for workers to perform their tasks easily?

How do I keep investors and lenders informed about the performance of my business?

View the entire video for helpful, informative tips on getting your website up and running today!

 

The Idea of Business Enabling Microservices

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.

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.

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.

So Python Finally Beats Out Java

With Java having become so popular among professional, enterprise developers, one would think it would reign supreme among techies. But with the fast rise of Big Data and Cloud Computing thanks in large part to Apache Spark, Python has edged out Java as the most popular development platform, according to a  comprehensive 2019 StackOverflow.com survey. Another interesting fact is that when it comes to learning the latest and greatest technologies, almost 87% of professional developers say they are self taught without taking a formal course. Read more here…

Solution Architect? Enterprise Architect? Application Architect? What’s the Difference?

By John Conley III

In the IT world, and in particular in the software side of IT, the word “architect” has evolved into a gray, confused mess, to be honest. I like how Geeks with Blogs humorously stated the 2 biggest misconceptions about the architect role:

•An architect is simply a more senior/higher-earning developer with a fancy title
•An architect is someone who is technically useless, hasn’t coded in years but still throws around their weight in the business, making life difficult for developers

So what is an architect? The Gang of Four design patterns authors used the term in honor of real world building architects from the real estate world. These professionals create blueprints for houses and commercial buildings that a construction team takes and executes to the satisfaction of the original buyer. How does such an architect come up with the blueprint in the first place? They either work with a buyer to elicit that buyer’s vision, or they commission a focus group of people if they plan to speculate on the next generation of building trends. In either case, they start with a vision and use their education and skill to come up with a blueprint that makes sense to the construction team.

Similarly, IT Architects must also start with a vision from a buyer (executive stakeholder or business owner or their representative employee). Ideally, this vision is articulated in the form of a user story, but can come in the form of a plain vision statement or brainstormed list of requirements and desired outcomes. This vision often leads to the need for a software solution to be developed, which in turn drives database requirements, infrastructure requirements (hardware and networking capacity), security requirements, test planning, and software product planning beyond the initial production release (Product Management and DevOps). The “technology game plan” architectural blueprint to coordinate these downstream tech roles is often embodied in what’s called a Solution Architecture Design (SAD) document. (I am writing an article called “How to Write a Technology Game Plan for IT Projects” soon, which should help simplify the SAD template).

So how did the role of architect deviate from this simple concept?

Often, the architect word is not needed for every job title. An Application Architect role can be easily performed by a lead software developer, who works with a Solution Architect. A Solution Architect mainly evolved out of the software space and is a person who ensures that software developers have enough info in the technology “blueprint” to construct the solution using best practices, which sometimes include design patterns. For larger organizations, two or more IT projects may have very similar requirements. In this case, the Solution Architect also has to consider enterprise goals and constraints, such as legal, regulatory, and reusable components to be shared across projects.

As such, such organizations put together a team of Enterprise Architects to maintain a repository of reusable components, design patterns, and related enterprise policies. An Architecture Review Board is often employed to allow Solution Architects to present a Solution Architecture Design document to get approval before proceeding to the next phase of the project beyond the Vision phase (Inception or Initiation or whatever term you prefer). For some organizations, the Enterprise Architect role has been expanded to include Infrastructure Architecture. This has aided in some confusion.

An Infrastructure Architect is focused on client and server hardware requirements, and sometimes even network capacity planning. Since Enterprise Architects have traditionally come from the software development ranks, it is better to have an Infrastructure Architect as a member of the Enterprise Architecture team, rather than confuse the two. Possible naming candidates would be Enterprise Software Architect vs Enterprise Infrastructure Architect. Similar confusion has evolved with respect to Database Architects/Data Warehouse Architects. Enterprise Data Architect might help with such confusion as well. An article on LinkedIn by Murad Yousuf goes into more detail about the differences in the roles.

This article is an evolving one, so be sure to bookmark it and come back for the latest updates.

BPM is dead. Long Live BPM!

Long live BPM! Business Process Management, BPM for short, is close to couple of decades old. I feel sad for the companies that make Business Process Management (BPM) Software. Reason? They have been fighting the perpetual battle of adapting to the change that has been plaguing this category.

At first I think the BPM Vendors got the basic premise wrong. Early stage BPM softwares were heavy duty integration middlewares. They were built on the premise that large enterprises already have the “Apps” and they are not going to redo it. But those legacy apps lacked a “process” layer. So, if you slap a “layer of process” on top of the “legacy apps” – viola, you have a BPM enabled system. It didn’t turn out so easy.

via BPM is dead. Long Live BPM!.

Gartner BPM Summit 2014: Implementing an Application Rationalization Program | MicroPact

In an insightful session here at the Gartner BPM Summit in Las Vegas, analyst Andy Kyte discussed the need for application rationalization and how BPM can play a role in such an effort. In this post I will highlight the points that jumped out to me, and I will also look at them in the context of Case Management and BPM.

Application Rationalization in the Enterprise

Application rationalization is an enterprise wide program that can help sort out the bloated application portfolio, and provide guidelines on how an organization should invest in applications. Such an effort is generally multiyear and should be revisited at constant intervals.

via Gartner BPM Summit 2014: Implementing an Application Rationalization Program | MicroPact.