In an increasingly fast-paced, service-oriented economy, enterprise architects and their business counterparts have to grapple with changing business needs and the challenges of inter-departmental communication. Often, the work of enterprise architects is lost in the fray as capabilities go unused and money is wasted, according to researcher Jeanne Ross. In the first part of this two-part interview, SearchSOA’s Jack Vaughan discussed these and other issues with Ross, Director and Principal Research Scientist at the Center for Information Systems Research (CISR) at the MIT Sloan School of Management, after she recently keynoted The Open Group Conference in San Francisco.

Download this free guide

Instant download: Applying DevOps to the BPM lifecycle

Modern BPM systems must be compatible with the DevOps approach and employ DevOps best practices to aid application development.

More expert advice from MIT's Ross:

enterprise architecture, we build capabilities, such as access to data and solid underlying platforms, that allow us to reuse systems and business processes, and these capabilities basically enable the business. It’s certainly been the claim of most enterprise architecture initiatives - as we build out better architecture the idea is you’ll be able to get to the data that you need to make the decisions you need to make, and you’ll be able to make them better. You’ll have automated business rules and you’ll have single systems that are shared.

The bottom line is that most organizations are disappointed once the enablement is there, and instead of saying, “Great! We’re enabled. Let’s get going,” there’s a tendency to say, “Well, yeah, but it doesn’t quite do this yet.” Or, “Yeah, we want to do that but that’s not quite the way we want to do it.” There’s just this futzing around, basically, after it’s in.

Architects have to take on greater responsibility for the exploitation of capabilities.

Jeanne Ross, MIT

My sense is that architects should give that up. They should stop saying, “Our goal is to enable,” because there is insufficient business value that comes from saying, “We’re going to enable business.” There’s an assumption that architects get to hand this stuff off – “We built capabilities, now it’s your job.” I just think that it undermines architectural efforts because people are too busy. They don’t take it on. Architects are going to have to take on greater responsibility and/or concern for the exploitation of capabilities.

So if we’re putting in a single database so that everybody can make better decisions about servicing customers, I think architects are going to have to say, “That’s what we’re going to have to make sure people do.” And let me just stop there, because I think the explanation is that enablement assumed that somebody would exploit. And it assumed that we would have capabilities in place that people are using. Exploit simply means using them and basically using them to death, squeezing every ounce of value we can get from a capability we’ve created. We thought architecture/IT would enable, and business people would exploit.

What we need to understand as architects, if we really want these capabilities to be exploited, is that we have to take a lot more responsibility for the exploitation piece.

Q: The CISR at MIT has delved deeply here. What are companies actually doing in the real world? What pressure do they place on the enterprise architect?

A: The trick for architects is that they aren’t obviously going to be the people that exploit [IT and business capabilities]. They just have to be thinking ‘’exploitation.’’ What we’ve learned from these great companies is that people – particularly senior-level people – identify opportunities for exploitation, a readiness to exploit. That puts pressure architects to stop trying to develop sophisticated, complete, large-scale capabilities, and instead respond to the moment.

Q: So architects shouldn’t focus on building large-scale business capabilities?

A: The idea for architects around exploitation is to put in little things that people can start using immediately and to recognize from those little things what needs to be done next.

The thing that doesn’t change is that architects still think big. They still think about the major capabilities the organization needs. But what changes is that instead of saying, “Okay, here’s the two, three, four, five-year project to get this all in,” they say, “What can we do in a very short period of time to get people to start using this, and to build towards the capabilities that we want?”

A large insurance company such as Aetna, for example, may have built up thousands of products and all of their systems were organized around insurance products. And what they realized is that was not how they were going to ever satisfy their customers. They wanted to know their customers and the customers’ products, not the Aetna [view of] products and all the customers that bought it. If you want a single face to the customer you think of the customer as the center of universe, not the product.

Now, that’s a huge transition - to say, “I’m going to fix that. I’m going to change my capabilities so instead of knowing products I’m going to know customers.” You basically turn your company upside down. And what [Aetna] did was the CEO said, “I want a dashboard. I want to come to the office every morning and know how we’re doing in our different customer segments.” And, of course, IT people are saying, “Okay, well, we’ll work on that.” And they offered him in five months a proposal for a system. They did what they could do in five months. And it turned out it was brilliant because, of course, once he got it he started to recognize what he needed even more, he started to recognize what did and didn’t work about the dashboard. Meanwhile [the enterprise architects] are starting to build out this capability of knowing the customer, but they’re building it very incrementally as the capability is being exploited, as it’s being used, and that’s what’s defining the next thing that needs to be built. It’s not this big global vision. That’s the real difference. So it’s not that architects start exploiting. It’s that they start thinking about what could be exploited quickly – that’s what we’ll deliver even as we understand we want to build towards major capabilities.

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy