Cloud computing is not just a family of technologies related to off-site storage or virtualized resources. It also brings with it a way for IT professionals to think about their job and its workflow. In this guest post, Microsoft’s Buck Woody, who’s on the Microsoft Azure team, explains how the cloud affects the way that systems architects get their work done.
I know – I said I didn’t like the “cloud” term, but my better-phrased “Distributed Systems” moniker just never took off like I had hoped. So I’ll stick with the “c” word for now, at least until the search engines catch up with my more accurate term.
I thought I might spend a little time on how the cloud affects the way we work – from Systems Architects to Database Administrators and Developers, and Systems Administrators – a group often referred to as “IT Pros.” But each role within these groups has different aspects when using cloud computing.
In this post we’ll take a look at the role of the Systems Architect, and in the posts that follow I’ll talk more about the other roles in the IT Pro area.
The Systems Architect Role
What does a “Systems Architect” do? Like most IT roles, it depends on the company or organization where they work. (In fact, the term isn’t even specific to technology, but I’ll use it in that context here.) In general, a Systems Architect takes the requirements for a given system, and assembles the relevant technology areas that best fulfill those requirements. That’s a single-sentence explanation, and needs further unpacking.
As an example, a Systems Architect at a medical firm is presented with a set of requirements for tracking a patient through the entire care cycle. The Systems Architect first looks at all of the requirements for the data that needs to be collected based on business, financial, regulations, and other requirements, and then at how that data needs to flow from one system to another. They check the security requirements, performance, location, and other aspects of the system. They then check to see which options are available for processing that data, and which parts they should “build or buy.”
For instance, the requirements might be so specific that only custom code is the proper solution – but even there, choices still exist, such as which language(s) to use, what type of data persistence (a Relational Database Management System or other data storage and processing) will be used, what talent within the company is available for the system, and a myriad of other decisions.
All of this boils down to three primary vectors:
- Knowledge: Which options are available to solve problems, and what are their strengths and weaknesses.
- Experience: What has the System Architect seen and worked with in the past.
- Coordination: A system design is based on multiple factors, and one person can’t make all the choices. There will need to be others involved at every level of the solution, and the Systems Architect will need to know who those people are and how to work with them.
How the Cloud Changes Things
From the outset, it doesn’t seem that using a distributed system would change anything in the Systems Architect role. Isn’t the cloud simply another option that the Systems Architect needs to learn and apply? Yes, that is true – but it goes a bit deeper. Let’s return to those vectors for a moment to see what a Systems Architect needs to take into account.
Knowledge
The first and probably most obvious impact is learning about cloud technologies. But the important part of that knowledge is to learn when and where to use each service. It’s a common misconception that the cloud should be an “all or nothing” approach. That’s just not true – every Windows Azure project I work on has some element of on-premises interaction, and in some cases only one small part of a solution is placed on the Windows Azure architecture. Since Windows Azure contains IaaS (VMs), PaaS (you write code, we run it), and even SaaS (such as Hadoop or Media Services), a given architecture can use multiple components even within just one provider. And I’ve worked on several projects where the customer used not only Windows Azure and On-Premises environments, but also components from other providers. That’s not only acceptable, but often the best way to solve a given problem.
As part of the learning experience, it’s vital to keep in mind what you need to pick as key decision points. In your organization, cost could be ranked higher than performance, or perhaps security is the highest decision point.
To stay educated, there are various journals, websites, and conferences that Systems Architects use to keep current. Almost all of those are talking about “cloud” – but there is no substitute for learning from the vendor about their solution. I’m speaking here of the technical information, not the marketing information. The marketing information is also useful, at least from a familiarity standpoint, but the technical information is what you need.
Resource: For Windows Azure, the Systems Architect can start here.
Experience
Cloud computing is relatively new. It’s only been out a few years, and the main competitors are only now settling in to their respective areas. It might not be common for a Systems Architect to have a lot of hands-on experience with cloud projects.
Even so, there are ways to leverage the experience of others, such as direct contact or even attending conferences where customers present findings from their experiences.
You can also gain hands-on experience by setting up pilots and proof-of-concept projects yourself. Most all vendors – Microsoft included – have free time available on their systems. The key to an experiment like this is choosing some problem you are familiar with that exercises as many features in the platform as possible. There is no substitute for working with a platform when you want to design a solution.
Coordination
Probably one of the largest changes in the Systems Architect role that the cloud brings is in the area of coordination. When a Systems Architect deals with the business and other technical professionals, there is a 20+ year history of technology that we are all familiar with. When you mention “the cloud,” those audiences may not have spent the time you have in understanding what that means – and often they think it means the “all or nothing” approach I mentioned earlier.
I’ve found that a series of “lunch and learns” for the technical staff is useful to explain to each role-group how the cloud is used in their area. In the posts that follow this one, I’ll give you some material for those. For managers and business professionals, you’ll want to go a different route. I’ve found that an “Executive Briefing” e-mail is useful, consisting of about a page, with headings that are applicable to your audience.
This article was originally published on MSDN in 2013 by Buck Woody; re-posted with permission.