Enterprise Architecture is more than a technology |
 |
By Rob Barry
21 Jul 2009 | SearchSOA.com |
|
|
When The Open Group kicked off its 23rd annual Enterprise Architecture Practitioner's conference the list of discussion topics was led by the transformative roles of EA in business operations and the assertion that SOA is not dead, but part of the natural progression in enterprise organization. Architects are pointing to the latest version of TOGAF as evidence
|
|
|
|
|
IT organizations wanted to take credit for solving a problem, so they create a metric. But this isn't a metric that benefits the organization.
Jason Uppal
, QR Systems
|
|
|
|
|
|
|
|
|
|
that the enterprise is starting to take EA seriously.
There are still a great number of enterprise organizations out there that have not started to develop their EAs. Jason Uppal, chief architect at consultancy QR Systems, says implementing an EA is worth the effort, but requires a change in thinking. At the conference, Uppal will be giving presentations titled "EA in Complex Organizations," and "TOGAF Response to Stakeholder Concerns."
Evidence of this shift in thinking surfaced in the release of TOGAF Version 9 Enterprise Edition framework, Uppal said. Based on EA best practices as documented by the Open Group, TOGAF 9 brings Enterprise Architecture to the forefront of discussion.
"In IT organizations, we're moving away from being custodians of information technologies to custodians of capabilities," said Uppal. "The industry is starting to understand that architecture is more than a technology."
For a long time in a number of industries, the IT department has been thought of as providing the technology needed to support business. Uppal paints a picture where a well documented, standards-based EA can actually help drive business.
A newer role finding its way into a number of organizations is what Uppal calls a "business capabilities manager." These are architects with expert knowledge of both enterprise SOA and the business side of things.
But implementing a full-fledged EA can take years and forces an enterprise to structure its thinking in a way that keeps service development from becoming boardroom arguments.
"Where they're starting to get hot and heavy is in the all-around business architecture," said Uppal. "Now BPM and SOA all of a sudden became front and center."
Specifically, Uppal points to a progression of four stages when attacking a problem that can be solved by business services. First an architect must look at a problem contextually and really be able to define the issue and identify why it needs to be solved.
All too often, Uppal sees companies attacking four problems with four different teams when a good architect could have seen they are all pretty much the same.
After defining the need, an architect should then look at the problem conceptually, defining what must be done by the managers. Then one looks at the problem logically, setting down the actual business process. Finally an architect reaches the physical stage, which provisions technological and support resources.
"We've seen it where everybody in the IT organizations wanted to take credit for solving a problem," said Uppal. "So they create a metric, but this isn't a metric that benefits the organization."
When an organization implements a well-documented enterprise architecture with a savvy architect and governance practices reigning in the efficiency, Uppal says the benefits to the total cost of IT ownership are incredible.
|
|
|
|
