Application architecture changes force IT to adjust focus

IT departments need to focus on developers to meet the demands of businesses that are shrinking the turnaround time for new projects from years to months or weeks with their digital transformation initiatives.

That's the advice that Juan Orlandini, chief architect for the cloud and data center transformation division at IT consultancy Insight, offered to organizations that face adverse consequences after businesses rushed to the public cloud when traditional IT could not meet their needs.

In this interview with TechTarget, Orlandini discusses the ways in which the changing business needs have had an impact on IT departments, application architecture, infrastructure and tools. Orlandini has spent more than 30 years working with enterprise computing, storage, networking, data protection, virtualization and hybrid cloud technologies.

Should an enterprise architect focus more on technology or business needs?

Juan Orlandini: Anybody that calls themselves an enterprise architect better worry about the technology as well as the business because they're two sides of the same coin. If you have a great business process but you can't implement it in technology, then you have not done anything good. Vice versa, if you have the most awesome technology but it doesn't support your business, then what have you done?

Juan Orlandini

How have changing business demands affected IT departments and enterprise architecture?

Orlandini: Digital transformation is now playing a much bigger role in everybody's thinking. As things accelerated, the time to value for any new offering or service got reduced. Time to value used to be measured in years. You got a two-year headway to come up with a new product or a new version of that product. Increasingly, now we're measuring in months, if not weeks, the time to evolve a product and keep up with the competition.

When I started, most developers worked for IT. Over time, the developers started working for the lines of business. Developers went to IT to have their needs met, and when the IT teams weren't able to operate at the speed the business was asking for, the public cloud took off.

Increasingly, now we're measuring in months, if not weeks, the time to evolve a product and keep up with the competition.

But what public cloud has never done right out of the gate is give you all those other things that IT has always given you -- the process, the controls, the governance, regulatory compliance. So, in many places, public cloud became architecture by accretion rather than architecture by design. You built something and then you bolted something onto the side. Then all of a sudden, you had a hairy mess where you had different accounts and you didn't know who was spending what and how they all interacted with each other.

The fundamental problem was that we, as IT professionals, were targeting the wrong consumer. We were targeting the line of business, and the real value when you're trying to come up with new or better offerings is with the developers that are creating the new application or product. That is something the public cloud has done exceptionally well. They've always gone after the developer.

What are the biggest adverse consequences that organizations face as a result of the rush to the cloud to speed application delivery?

Orlandini: Top of mind is security by far. Developers considered security, but security is not what they are paid to do. Security professionals often were not included in the development of applications. Simple things that would have been caught in a security construct in a traditional IT environment were just not considered or not part of the development cycle. This is why you've seen some massive breaches at major organizations.

Another thing is cost management. We had a client tell us that junior developers are making multimillion-dollar decisions. They're increasingly educated to use the public cloud as the place to learn how to develop, so they use it. The next thing you know, there's a petabyte worth of storage and umpteen zillion cores of CPU. That junior developer made a multimillion-dollar decision because the application's going to run on that cloud and only that cloud. Once you start consuming APIs, you're locking into that framework -- unless you want to do a full-on rearchitecture -- because doing storage in AWS is different than doing it on Azure or [Google Cloud Platform]. The way you do networking and security is different. And it's different than doing it on premises.

You're leaving yourself open for vendor lock-in like you never have before. You had that with the on-premises players you've always dealt with, and now you have it with the three big cloud vendors as well. Their products and services are fantastic. But if you use any of them only in the way they offer it, you're locked in. If you develop for one kind of API, it's really hard to redevelop for a different kind of API unless you're very methodical. There are API gateways and other things that can help. But you've got to be deliberate about your choice, rather than accidental.

People have massively powerful tools now, but those powerful tools come with massive responsibility to make sure that you're using them right. The application might be on the right cloud -- but it might be that I should have architected it differently so that I don't get a million-dollar bill every month for the storage, the networking or the CPU. A different cloud, or a hybrid or private mode, might have been the better choice.

What can an IT organization do to prevent the unintended security, cost management and lock-in issues?

Orlandini: Focus on your new end user -- the developer. Make sure the developers have the tools and systems they need, and make sure the developer experience is similar to what they've been learning to do in the public cloud or in a containerized, cloud-native way. If you do that, the enterprise architecture tends to become much more palatable, consumed and viable. You can implement the controls and measures that traditional IT always has. Now the developers include security practitioners and architects and put security first and foremost in their designs. Because they're working with IT instead of around IT, it becomes better all around.

People will tell you that's DevOps -- developers working with operations IT. But DevOps to date has been primarily Dev that's learning how to do Ops, and not a lot of Ops learning to do Dev. And there's a new thing called DevSecOps, putting development, security and operations together. I don't necessarily like it, because Sec does not necessarily know how Dev and Ops work, and Ops doesn't necessarily know how security and developers work. But that's starting to happen, and if you can truly get that to work, that fixes a lot of problems.

What trends in application architecture are having the heaviest impact on IT infrastructure?

Orlandini: Containerized, Kubernetes, Cloud-Native architectures, with a capital C and a capital N, are driving infrastructure teams to think about how they implement, monitor and work with architecture differently. For some organizations, that's an incredibly natural thing to do. Google was a prime example of that. For organizations that are more traditional, that is extremely challenging. They've got to rethink a whole bunch of the dogma they operate on. What is the role of the network person? The storage person? Everybody in operations?

In the Cloud-Native ethos, it's challenging from both a technical perspective, as well as from a cultural perspective. On the technical side, you're going to have to learn new tools, new technologies, and new ways to interface and manage the infrastructure. From a cultural perspective, you're going to have to break down some barriers that you might not even be aware exist between the developers and the infrastructure teams, and between the different infrastructure teams that work with each other. That's a big ask for a lot of organizations.

In what ways do you envision the infrastructure changing with the latest trends in application architecture?

Orlandini: That's TBD, because it's not a foregone conclusion that Kubernetes and containers are going to solve everything. In fact, there's a lot of debate in the developer, DevOps and cloud-native community as to whether or not Kubernetes is the great tool for everybody. There's a lot of debate as to whether even containers are the right abstraction mechanism for everybody. There's work ongoing on serverless that's gained quite a bit of traction. There's a unikernel that might or might not grab some traction. There's debate whether you should do microservices for everything, or if monoliths are OK.

Like any good carpenter or mechanic, you've got to match the tool to the problem, not the other way around. An enterprise architecture team should look at containers not as a blunt instrument, but as a precision tool for precision problems. A consultancy we work with had a client with a CTO that was two or three years out of college. He designed the architecture for a product, and two years later, they're still working on the product. The investors are getting upset because they haven't even released MVP, minimum viable product. The consultancy found 40 microservices and six different database systems. On paper, it looked fantastic. But writing that code is a terrible nightmare. So, they simplified the architecture and reduced the number of microservices down to just a dozen. It's still the microservices architecture but with a much better design and implementation pattern. They turned around from having a huge cloud bill and a very slow turnaround time for their iterations into a much more viable approach. So, you've got to be careful when you're using microservices that you're not overengineering and overarchitecting because you've fallen in love with the technology.

The advice I would give is that you have to be nimble and adaptable. If your stance is, 'Our standard is,' monolith, microservices, serverless or whatever, then you're closing your mind to certain possibilities or efficiencies that might be gained from the others.

Do you think organizations need an enterprise architect or architecture team to combine the best of the new and old application approaches?

Orlandini: Absolutely. Enterprise software architecture and enterprise systems architecture are essentially merging. For a while, the only way they could merge was in the public cloud, but we're now getting on-premises tools that are similar to what's available in the public cloud. It's no longer provision me a virtual machine. It's now provision me a [continuous integration, continuous development] CI/CD pipeline. They build all the things necessary for the team to start doing development, and off they go.

Now enterprise software architects and enterprise architects have a choice. Do I do it on premises, and why? Do I do it in a hybrid mode, and why? Do I do it in a public cloud, and why? Do I do it in a multi-cloud way, and why? Or, do I do it in a hybrid multi-cloud way, and why? All of those come with financial decisions, software architecture decisions and infrastructure architecture decisions. It's not for the faint of heart. It could easily be a monumentally important decision for a business so they can scale, innovate and grow. The ones that do it well are going to do well in the market, and the ones that don't do it well are going to suffer.

Editor's note: This interview was edited and condensed for length and clarity.