Holy Grail still elusive in enterprise architecture strategy

No companies are close to where they want or need to be on their enterprise architecture journeys, in designing their people, processes and technology to deliver on their strategic goals.

That's the assessment of Jeanne Ross, a noted expert in enterprise architecture who recently retired as principal research scientist at the MIT Center for Information Systems Research. In this Q&A, Ross reflects on her 26 years of working at MIT in the field of enterprise architecture. In part one of SearchCIO's two-part interview, she shares her thoughts on the successes and failures of organizations that she studied. (Read part two here.)

What are the most important patterns you've observed with organizations that have been the most successful with enterprise architecture?

Jeanne Ross

Jeanne Ross: First and foremost, they totally understand what we call the operational backbone. This is the set of people, processes and technology that enable the basics. It enables the transactions to get processed. If it's a manufacturing company, it enables effective planning and delivery of goods. If it's a financial services company, it enables good understanding of customers and reliable, efficient, secure payments and processing. It starts with understanding how you get that in the ERP to CRM to banking engines to claims processing engines -- whatever is core to your business -- to zero in on what really matters.

Where so many companies went wrong is they didn't set priorities, and they tried to get everything standardized. They were pursuing massive systems instead of pursuing excellence in what matters most. The companies that succeeded got in some core systems accompanied by very disciplined processes, which helps them deliver great data around their core operations. If you don't have that, you're constantly cleaning up and reacting. But, if you do, you have an asset that a lot of companies are missing. Then you get to look beyond and say, 'How do we innovate? How do we take it to the next level? How can we take advantage of digital technologies?' This is something companies have been targeting since the late '90s, but most companies are still not very good at it.

That's step one. You've got to get the strategy and the design right. If you don't know what the essence of your business is, you can't design it. If you don't design the essence of your business, you can't deliver it. That's the enterprise architecture challenge. It starts at the operational backbone and then moves toward better and better understanding the components of your business that will be essential to your future. This then gets into learning how to assign accountability -- how you're going to marry people and technology so everybody can get stuff done that benefits the company but act somewhat autonomously. With big companies, if we do everything top-down, it's too slow. But, if you have a solid operational backbone, and you start assigning accountabilities for the components, you can absolutely move fast and do things your competitors can't do.

What are the biggest mistakes you've seen organizations make with respect to enterprise architecture?

Ross: There has been for many years this belief that some standardization is good, and more standardization is better. Part of this is because of the state of the technology in the late '90s and early 2000s. The way you brought any kind of disciplined process into your company was this massive system, like SAP, PeopleSoft and Siebel. Companies would fight to get them [thinking that] it's the only way to get good data, get your costs down and be able to integrate your processes for your customers. So, you'd get that you need these standards, but at the same time, they don't always work in a complex, diverse business. We just saw massive systems failing because they didn't fit. Your choices were: Don't even try to get that massive SAP system into your diverse business, or simplify your business so you can bring that in.

What's happened since are two things. First of all, people are starting to wrap their heads around that they do need standards and discipline, but they need them in smaller components. And the technology now allows that. We can do more software as a service, for example. Salesforce was one of the leaders in providing that capability. The componentized availability of standards and discipline and process is much more pervasive now. You can assign discipline to parts of your business instead of saying we're going to put it everywhere. That's been a big change.

And, simultaneously, people are getting better at it. They understand that if you want to rely on systems and have more disciplined data, you have to pick some focal area and say, 'OK, I'm bounding it. This is what I'm going to discipline. This is how I'm going to discipline it. And we're really going to make it happen.'

I do think we're seeing progress. When we wrote the book Enterprise Architecture as Strategy in 2006, we were saying to companies, 'Figure it's going to take you six to 10 years to discipline your processes.' The thing that has changed since that book came out is now you can do it in smaller pieces and make real progress in a year.

Where do most companies stand now in their enterprise architecture journeys versus where they want or need to go? What is the Holy Grail, so to speak?

Ross: No one is close to where they want to be, but the tougher part is that the 'where they want to be' is not stable. As you design a company so its people, processes and technology can deliver on strategic goals, the goals evolve, so the design requirements change. The Holy Grail is when the company formally recognizes the need to design holistically. It's more common for companies to architect technology, not recognizing that to benefit from that effort, it's essential to design the people and processes, too.

What we can do now that we could not do 15 years ago is digitally connect to partners. This is something research-wise we've been looking at since the '90s. But it wasn't real then because too many internal processes were such a mess that the idea that we could seamlessly connect with another company whose internal processes were also a mess was, practically speaking, crazy. It wasn't going to happen.

What we're seeing now is the beginning -- and let me emphasize this is the beginning -- of companies saying, 'We'll get really good at a narrowly defined digital offering, and when our customers want more, and some of what they want is very specialized, we'll connect with a partner who can meet their needs.' A great example is Schneider Electric. It is one of the few that really exemplifies where a company can and must go. Internally, Schneider still has issues, because it acquired 100 companies, which gave it 100-plus ERPs and a real mess. But it started cleaning up the pieces that were keeping it from becoming the company it wanted to be -- a company that didn't just sell electrical equipment. That had been the historical value proposition, but it wanted to move to intelligent energy management solutions. To move there, it needed to take not only the equipment it manufactured, but also the data that the equipment could generate, and help customers manage energy sourcing and use for greater reliability and cost effectiveness.

When Schneider Electric is providing solutions to customers, it has a lot of internal capability to explain what's going on with their equipment and their use of energy. But quickly, the customers start saying, 'Oh, this is good. Now I need you to help us with, say, the energy required to clean food manufacturing equipment.' There's a lot of implications around energy when you're tuning the equipment, and Schneider said, 'Good Lord, that is very specialized. I don't think we want to go there.' So, rather than try to become something it wasn't or go out and acquire a company, it partnered. And basically, if you design your systems right, and you have your accountabilities right in the company, this actually can be easy. And that's what they are just starting to do. You can buy all kinds of services from Schneider partners through the Schneider marketplace.

But that's the future path. You don't get there unless you do the basics, get your operational backbone, and then start to recognize the components that are going to lead you to a business that provides solutions for customers and can move beyond what you personally can do by connecting with partners that can supplement your offerings.

Do you think enterprise architecture is more conducive to certain vertical industries than others?

Ross: The thing we found in study after study is that companies that did amazing things with enterprise architecture also simplified themselves. When I was describing this in talks and classes, people would say, 'Well, it would be easy for UPS or Lego to get it right. They're simple companies.' And I said, 'No, no, no. In getting it right, they simplified themselves.' That's the brilliance. They got rid of diversity and variability that wasn't doing them any good. That's the genius of enterprise architecture. Your architecture has to help you focus on what kind of simplification you can and will do. And if you don't let it do that, your enterprise architecture doesn't bear any fruit.

The COVID-19 pandemic is not the first crisis you've encountered during your long career. What were the most important lessons you took away from prior experiences?

Ross: One of the great benefits of being good at enterprise architecture is you're more ready for a crisis. You can respond better. You can pivot, because enterprise architecture gives you a real awareness of what your company can just plain do. We're not trying to go, 'Oh my gosh, our whole business doesn't work.' We find what we keep, and then we respond around the edges. You're more agile in responding to whatever the crisis demands. It does not ensure that you'll perceive the crisis effectively. It does not ensure that you will choose the right path, but it makes you capable. It helps you position what you've got and where you need to go and make good decisions faster to get there.

Have you found that most successful companies use enterprise architecture frameworks and tools?

Ross: Great companies that understand design and strategy use tools. They need to organize things. The tools assign accountability to someone. But don't keep looking for the tool that's going to solve all your problems. Agile methodologies are a good thing, but if you think Agile methodologies are going to solve anything for you, they're not. This is about clarity of purpose, and then realizing that there are tools in this Agile methodology approach that will be useful when you're absolutely clear about what you're trying to get done. The architecture tools are the same. You don't want to get too married to tools or how they're used because they take on a life of their own.

The risk of architecture is that it has attracted people who like neatness. They can draw a picture. They can say this is the way it should be, and this is a thing of beauty. But it isn't reality. What you're looking for is somebody who can identify the messes that are causing problems, but they can also live with some of the messiness. They can say, 'OK, this is not a problem, but this is, so let's fix this.'

Is Agile methodology compatible with enterprise architecture?

Ross: Yes, they are tightly wedded because if I try to use Agile methodology and have no sense of the higher-level design, I will create a mess. Agile methodology with no higher-level architecture is a disaster. On the other hand, if I have a whole lot of high-level architecture, and my solution is, 'OK, I'm going to do these massive projects that are going to have two- to three-year time frames,' I'm not going to be able to keep up with the daily changes that happen in my company.

I don't want to argue against a three-year plan. You want a roadmap. But it has to be a very flexible roadmap. You are always moving in a direction. You are not moving to an endpoint. This is the problem we had with enterprise architecture, if we go back to the '90s. Our assumption was we were going to accomplish an endpoint. But the company changed. The technology changed. We never got there. So, if we make our future plan more about the direction and the general capabilities that it provides, and we roadmap in much smaller increments, then we constantly make progress.