I have found that the "business requirements" pointed by Rob are usually coming from the Operational Support Process groups, they think in tools and narrowed activities. If you talk to business people above that level, they refer to business tasks and their maximum technical exposure is at the level of operational or reference databases, or Web applications; they do not know about screens, fields, and so on. I believe the IT has to get requirements from the latter business level. Operational Support Process groups are equal to an Excel spreadsheet - they do not matter to the business tasks, they are the answer to HOW realise an operation with existing resources. If resources change, this HOW gets obsolete right away.
An "idea of being business driven" is based on real business tasks, services, functions, and features, not on the automation of support operations that only make the Business-IT gap even deeper day by day. - Michael ________________________________ From: Rob Eamon <[EMAIL PROTECTED]> To: [email protected] Sent: Monday, November 3, 2008 4:43:02 PM Subject: [service-orientated-architecture] Re: Rhody tells you how to sell SOA --- In service-orientated- architecture@ yahoogroups. com, "Nibeck, Mike" <mike.nibeck@ ...> wrote: > > The idea of being business driven is almost non existent anymore. I agree, at least in part. A part of the reason is possibly this: business "requirements" rarely are. Instead, business requirements documents are usually full of technical decisions and solutions. Screen shots. File format layouts. Screen flow wire diagrams. All great tools. None are geared towards defining business requirements. But perhaps its just a naming issue. It seems perfectly reasonable for folks in groups other than IT to specify functional solutions/approache s in many cases. e.g. "We need a field to capture XYZ on screen ABC." While there is a business level need lurking behind that, it's a specific technical solution, not a business requirement. For many things, this level of specification is fine. For other things, it can lead to tunnel vision. Getting funding for an "SOA project" is similar to the above problem. It assumes an approach before understanding the needs. It assumes the approach is *the* important part. -Rob
