Solution architect, reinvent yourself for the cloud

Solution architects are facing extinction unless they reexamine and reinvent themselves

The role of the SA (solution architect) is a prestigious one. Responsible for the design, planning, deployment, and management of enterprise solutions, the SA is a seasoned veteran with deep knowledge and a broad range of skills.

Sad to say, the role of the SA may become obsolete in a cloud-oriented world where everything is turned over to the vendor (be it Microsoft or otherwise) to handle the network infrastructure, data management, and other core services. Whereas a solution architect would typically determine the technology foundation for any new deployment, drawing on a wealth of experience and research into best-of-breed options, the cloud vendor is making these calls now. Welcome to the McDonald's "choose a value meal" approach to modern, cloud-based solution design.

Many SAs I speak with these days are focusing their energy on strategies for migrating from on-premises Exchange to Office 365. While their knowledge and skills may remain relevant through the migration process or while architecting hybrid solutions that mix on-prem and cloud, their skills eventually will become obsolete as we shift from on-premise infrastructure and solutions to IT as a utility.

Or so it seems.

"Plug in and go" cloud offerings are generally an excellent fit for the small business. But the larger businesses that SAs cater to require much more than the base design provided by a cloud vendor.

Let's consider the case of Office 365, for example, with a clear focus on the messaging side.

At the core of Office 365 communication and collaboration is Exchange server running in the cloud (aka Exchange Online). From an architectural perspective, this computing workload -- the solution for email services -- is one of four building blocks that on-premises messaging architects focus their attention on. The others include long-term data management, gateway solutions (for security, mail routing, and so forth), and availability or DR solutions.

As we move to the cloud, we need to solve for four primary workloads or services. In addition to the mailbox services, which Microsoft handles through Exchange Online, we need to figure out how to provide gateway services, long-term data storage, and DR and contingency services.

As an SA, you typically look for ways to add best-of-breed or best-in-class pieces to your environment. For Exchange in your data center, your gateway services, long-term storage, and DR solutions might not come from Microsoft. However, in the cloud, Microsoft provides base-level solutions for all of these areas. It cannot leave it to chance that Office 365 users are going to put those pieces in place properly.

But here's where the reinvented SA (aka SA 2.0) comes in: It's incumbent upon the SA to understand the cloud architecture. The shift to the cloud does not necessarily leave the SA behind, but changes the role -- in this case, a move toward risk management cloud messaging architectural solutions (risk-managed email architecture for short).

SAs need to consider the customer they're working with and be able to determine if the base offering from Microsoft is enough. In the case of email services, you may need to look at your long-term data plan with Microsoft, which might be a concern from a data portability or compliance perspective, and the ability to provide proper management and discoverability.

Look, we all know a product like SQL Server is fantastic, but when we think "big data," we think Hadoop, right? Not every organization needs Hadoop, but when it makes sense -- when the solution architect says it makes sense -- it's time to build that into the design. The same is true with regard to cloud-based email management. Just as on-premises Exchange is surrounded by an ecosystem that SAs can reach into to add to their design, there is a similar ecosystem within the cloud for Office 365.

The is true of the other building blocks as well. Microsoft has taken solid solutions such as Exchange and stretched them and added to them so as to provide for the other building blocks. This will work well in many cases -- but not all.

For example, when you blueprint your move to the cloud, as a "Cloud SA" you have to consider if the built-in security offerings are "good enough" for your needs or if a layered approach would be better. The same questions apply to availability options. Does the organization you are migrating need not only availability but also some form of disaster recovery? (DR doesn't currently exist within Office 365, where Microsoft is content to provide native data protection -- so no backups.)

In the cloud as on premises, when you understand the architecture and can make suggestions based on each of the essential computing workloads for a messaging solution, you remain relevant, not only when considering Exchange but when looking at all forms of cloud computing (services, platforms, and infrastructure) because you now have to mitigate risk. Start with the base building block that Microsoft has done a fantastic job with (Exchange), then determine whether the other blocks are adequate for your customer.

Become a "risk management" expert for the cloud: a cloud solution architect. Doing so will help you to remain truly relevant in this ever changing world of clouds.

Copyright © 2015 IDG Communications, Inc.

How to choose a low-code development platform