How Enterprise Architecture Heads off Integration Problems

Loraine Lawson
Slide Show

Strategic Integration: 10 Business-Building Tips

Ten ways that companies can use integration and integration-related strategies to build business.

Last month, I confessed to having some doubts about enterprise architecture, particularly when it comes to why the business should buy in to promoting enterprise architects outside the domain of IT. I noted, however, that it seemed to be paying off for Del Monte. Its CIO reports EA reduced integration work and the complexity of data.

 

My post received several responses that ranged from defending EA to war stories about architects engaging in pedantic arguments in front of the CEO.

 

This week, I discovered that enterprise architect Todd Biske - whom I referenced in the article - actually wrote a response on his own blog to address my doubts. It's a nice response, but I especially appreciate his explanation of how enterprise architecture can impact integration:

In my opinion, the way to do this is through a practice of portfolio management, which I believe needs to be at the core of an enterprise architecture practice. Portfolio management isn't a one time application rationalization effort, it's an ongoing discipline that must be integrated into the decision making process for what activities (projects) take place. ... If we do an effective job of this, we better understand the boundaries and dependencies between the capabilities that need to be provided. By better understanding these, the task of integration becomes easier, because it's a forethought rather than an afterthought.

I like that - integration as a forethought - and I can certainly see the value in that.


 

Upon further reflection, I think the real question isn't why the business should support enterprise architecture as a practice. Enterprise architecture as something you do - as a verb - makes perfect sense. But I'm still not convinced the business will readily adopt enterprise architecture as a job description, particularly if it comes out of IT, especially when it turns out you don't have to be an EA or come from IT to engage in enterprise architecture.

 

Mike Rollings, a VP at Gartner Research, commented on my post:

The dual perception challenge lies squarely in the hands of practitioners and the EA community. Practitioners should stop thinking that success is measured by how well the organization can quote EA terminology or by solely evaluating the maturity of EA. Instead, they should focus on being business relevant.

Biske points out that IT is locked in a bit of a political conundrum. It's seen as a supporting function, which keeps IT from having real input into the big-picture decisions, even though IT outgrew those pants a long time ago. Frankly, it's harder every day to disagree with that assertion, given the strategic importance of data, social networking, mobile devices and other technology-related business issues.

 

But then again, as Warren Weinmeyer recently pointed out, that may make sense, but it doesn't seem to be happening in most organizations. Writes Weinmeyer:

There is a clear trend in leading-edge corporations (which are generally also the ones that consistently rate the value realization of their EA practice highly) to in fact move EA out of IT: in these companies, you will find EA teams are staffed by people from many segments of the organization, not just IT people. Having said that, the reality of the situation for EA is that, like hygiene, many more people talk about it than do it well. In the majority of companies, EA is in fact nothing more than IT Architecture: and it is in this context that EA (really, "faux-EA") has the most difficulty in justifying its value.

Both Biske and Weinmeyer agree on this: If enterprise architecture is going to break out of IT, it has to transcend the project mentality and focus on the big picture.

 

Says Weinmeyer:

Resist project level responsibilities for your EA team. If you have to accept them for a short time, develop a plan with your superiors to instill architecture skills into the project delivery staff.

Biske also warns that EA has to avoid being just another resource on a project. Instead, he suggests, focus on application and technology portfolio management.



More from Our Network
Add Comment      Leave a comment on this blog post

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

null
null

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.