Yes, if the guideline is going to include more than the IT constraint, it should be written by somebody with a broad understanding of business. (I read Porter is not enough.) :-)
I meant "IT" with people and organization included. Realizing an executable system requires people to operate the technology too. Some business people just focus on the technology, but I feel that's not enough to build a working system. Even if there is a technology, if people can not operate it efficiently, it's useless. H.Ozawa --- In [email protected], "Rob Eamon" <[EMAIL PROTECTED]> wrote: > > A corollary: Technical people without a broad understanding of the > business should not be writing modeling guidelines. :-) > > The challenge in creating such guidelines is understanding all the > pertinent constraints, not just the technical aspects. And for the > technical aspects, the key is in understanding which technical aspects > are architecturally significant and which can be safely viewed as > implementation details. > > Side bar: I prefer "technology constraints" as opposed to "IT > constraints" due to the overloading of "IT" as both technology and > organization. "IT constraints" tends to sound like items the IT > organization dreamed up. > > -Rob > > --- In [email protected], "htshozawa" > <htshozawa@> wrote: > > ... > > Now people may be wondering where the business aspect comes in. The > > point is to create a BA models within the confine of IT constraints > > dictated by the guideline. We should be focusing on the business > > aspects within the IT constraints. And no, business people without > > technical expertise should not be writing modeling guidelines > > because they do not what can and cannot be technically created. :) > > > > Will post my link to my diary page when I write it up. > > > > H.Ozawa >
