The business side has silos too |
 |
By Jack Vaughan, Editor-in-Chief
23 Jan 2009 | SearchSOA.com |
|
|
SearchSOA.com talked recently about SOA trends with Brenda Michelson, Program Director for the OMG-managed SOA Consortium. Topics of interest included the interaction of the business side and the enterprise architect team.
The business side of the organization may have its criticisms of software development, especially in terms of speed of development. But neither side is blameless. Enterprise architects may go to great lengths to understand how a business works, so the business can be well represented in software services; but they may find that the business itself has vivid dysfunctional aspects.
Over the years we have heard a lot about technology silos. Now we hear more and more of business silos. IT and development teams at work in recent years on service-oriented architectures discovered that parts of the organization were hard-wired into certain behavior, and were not amenable to the methods of services.
If the business side has silos too, what is an enterprise architect to do? Cajole!
We talked about this phenomenon recently with Brenda Michelson of the SOA Consortium. The business side's engagement with IT can be enhanced by services, she said. A sharing environment must exist, however.
"As people move along in SOA they start to see some successes and some challenges that don't relate to the technology so much, but rather to their organization itself," she said.
"It is important how IT and the business interact with each other," said Michelson. "If the business is used to acting in silos and having their own money to fund [what they want to do], then they are going to be less successful."
Business departments, she indicated, may feel they already work effectively as silos when it comes to such key matters as customer records and the like. That means an effective enterprise architect has to have high-grade interpersonal skills, and must be able to influence business stakeholders to see the overall benefit in a change in behavior.
You can't make the business "jump through hoops," what you can do is cajole.
It is really about understanding how the business works. If the business wants change you need to convincingly explain that change can be accomplished most readily if the business logic is not all hardwired together.
Added Michelson: "Your first concern is to deliver business capability. At the same time you need to keep an eye on your IT investment and your IT run rate." You don't want to accumulate a technical debt, she said, where the teams in your own department have to constantly be mindful of a wide variety of architectures and logic paths.
This is just another part of the unique balance act architects face today. Finding ways to improve the way things are done, while still doing things in frequent iterations. "You don't want to redeliver the same thing every year - but you don't want to ask for three years so you can be 'architecturally pure,'" said the SOA Consortium's Michelson.
|
|
|
|
