The big cloud vendors tout many reasons for running IT infrastructure in the cloud. A very prominent benefit is “accelerated innovation and delivery.” That’s a powerful selling point because every IT manager I have ever known wants to deliver better results, faster, and at lower cost.
However, it seems that the less IT managers know about doing actual hands-on IT work, the more demanding they are. They just don’t grasp how hard these projects can be. Conversely, my experience has taught me that most IT managers who came up through the ranks as software developers, system administrators, and QA staff members know that it is extremely difficult to pull off development projects quickly and with high quality. That makes these veterans more protective of their teams, more adherent to standards, and more likely to push back against scope creep. They know the sort of sand traps that come from ignoring development issues.
Unrealistic Demands Cause Shortcuts
Often, while visiting customers and prospects, I have found the demands to complete software projects quickly and cheaply to be one of the biggest problems in the IT industry. So many times, I’ve heard DBAs and developers tell me “Well, it’s supposed to be done in 3 months. But that’s management’s pipedream. It’ll take months more than that."
Unrealistic demands cause many managers to take shortcuts, usually at the very end of the project or at the very beginning since the development phase is most likely to have overruns. For example, I’ve seen multitudes of projects where the development manager cut QA and testing time at the end in a vain attempt to meet deadlines, while failing to consider that QA and testing would uncover issues that would ultimately need to be fixed. A similar problem happens at the outset of many projects when managers try to avoid spending all that time designing and planning a proper solution when they could get the software developers writing code now. NOW! IT organizations frequently entrust the entire design and architecture to developers, who may or may not know enough to build a system that is sufficiently robust to meet the business requirements at enterprise scale.
Cloud Applications Need Architects Now More Than Ever
Has the cloud made this better? If you read the press releases from the likes of Microsoft Azure, they do indeed stress faster time to market. But I would put posit that the cloud makes robust architectural designs for new software projects more important, not less. In other words, if you’re building new applications for the Azure cloud platform, you need a talented and experienced application architect. Neglect this role at your peril.
Here’s a case in point based on the recent release of the public preview of Azure Data Share (https://bit.ly/2KFmMKU) that came out on July 11. Glancing at the name, I can see that it’s a new service offering from Azure and it has to do with sharing data. OK. Nothing scary there. But wait—aren’t there some other Azure services that help with sharing data? Yes, in fact there are LOTS. We can choose from Azure Database Migration Service, Azure Data Sync, Azure Data Factory (ADF), Azure Data Box, and probably one or two that I’ve lost track of.
But that’s not even all the options since we can also use what exists within Microsoft SQL Server to move data around. On the SQL Server side, we have Service Broker, Replication, Log Shipping, Import/Export Wizard, BCP, Availability Groups, DACBAC and BACPAC, PowerShell scripts, SQL scripts, passing XML or JSON docs, and more. Whew! And how much does any of this, on-prem or in the cloud, cost? Most developers don’t know.
Knowing the Best From the Rest is an Architect’s Job
Software developers aren’t expected to know about every option available to satisfy every requirement in a coding project. They’re expected to crunch code. Knowing about all the options, their intended use case, the problem they solve, and when to apply one approach over the other is the job of the architects—and it is a role that is dangerously omitted from more and more projects.
I recently asked Shawn Melton, a Microsoft MVP and project engineer at Pythian, for his thoughts on this topic. He said, “Take ADF, for example. There are a number of pieces on networking and applications that have to be deployed before you can even start to use ADF against an on-prem source. That adds overhead and management requirements for maintaining those pieces outside of what the developer must do. In most cases, a developer considers which one is easiest to develop against and maintain the code. An architect will consider the whole picture, down to the cost of the service(s) being used for a given project. The architect (should) have all the information and data to analyze whether a service is right for the price and the level of effort to implement.”
Enterprise IT is full of applications designed and built by a single developer or a small team. Many of them struggle to perform. But it’s not their fault. Developers crunch code. Architects design robust and scalable systems. An architect knows the limitations and restrictions of their options, balancing those against the business requirements and budgets of the enterprise.