Michael, The struggle (induction) has been done once for all so the rest of us simply use deduction which is not a struggle but a disciplined systematic practice free of ambiguity, bias and uncertainty. Struggle means unclear in conception and imprecise in implementation. I understand where you are from and agree all of us are struggling today because unclear and imprecise in software development permeate in the practice of software engineering today.
My point is that some day we will have a software development methodology with which we do not have to struggle that is the focal point of my current effort. Cheers, Jerry --- Michael Poulin <[EMAIL PROTECTED]> wrote: > Unfortunately, not, Jerry, while I tend to agree > with your explanation over all. > > My point, and you perfectly described it, is that OO > does not provide enough abstraction to model real > business world today. > > The "...business and IT aliance is not what we > struggle to do, but a > nature evolution of IT" can happen only if we > struggle to do it. If we stop design IT solutions to > the business requirements like they are the last > absolute truth and came to us (IT) every time > suddenly, from the blue, we can start build services > as entities that are ready for changes in the scope > of our business models. > > The struggle here is with those who do not want to > do it due to any reasons. > > - Michael > > Jerry Zhu <[EMAIL PROTECTED]> wrote: > OO business concept for OO is not > as important as SOA > business concept for SOA. In other words, as we > move > up in abstraction, business model becomes > increasing > important, hence increasing business and IT > aliance. > > The higher abstraction the more inclusive, the more > business aspects IT includes. OO includes business > activities, a level below operation and hence does > not > address operational goals. Or operational aspects > of > business are not part of unit of analysis of IT. > therefore business and IT aliance are at the level > of > business actvities. Whether IT meets business > goals > is not in the conversation. > > As we move up to SOA, service, the unit of > analysis, > includes subprocess, or operational modules,starts > to > address operational goals. Hence greater business > and > IT alliance. > > As we continue move up to BPM, the unit of analysis > becomes business process that adresses strategic > goals. Therefor business strategy is part of > discussion of IT implementations. Therefore > business > and IT aliance is not what we struggle to do, but a > nature evolution of IT. > > I hope I answered your questions, Michael. If not, > feel free continue to explore. It is fun and that > is > why we do it. > > Jerry > > --- Michael Poulin <[EMAIL PROTECTED]> wrote: > > > Just out of curiosity, can anybody point me to an > > example of live "OO > > business concept"? > > > > I would agree with Jerry - we have the > disconnection > > between the business and IT now (and trying to > fix > > it using SOA) partially because IT evangelized OO > > and has forgotten to tell business that "We must > > have OO business concept for object technologies > to > > be useful"... > > > > - Michael > > > > Jerry Zhu <[EMAIL PROTECTED]> wrote: > > > --- Michael Poulin > > <[EMAIL PROTECTED]> wrote: > > > > > When we say BPM, what it stands for (for IT > and > > for > > > business): business process management or > > modeling? > > > > > > - Michael > > > > Michael, > > > > I think that business concept must be hand in > hand > > with coresponding technology suites. We must > have > > OO > > business concept for object technologies to be > > useful. > > We must have functional decomposition business > > concept for procedural languages to be useful. > We > > must > > have concpet of how machine operates for > Assembly > > language to be useful. We must have BPM > business > > concept (activity/performance mornitoring > > management, > > customer satifaction, strategic/business > alliance > > etc) > > for BPMN, BPEL etc to be useful. > > > > The evolution of IT is growing abstraction from > 0's > > 1's (no abstraction) to BPM (the highest > > abstraction). > > Each level has corresponding modeling units > such > > functions for functional orientation, objects > for > > OO, > > services for SOA and processes for BPM. Higher > > level > > units have lower units as constituents. > Therefor > > higher level units are more abstract. The more > > abstract the larger idea it is the more ground > it > > covers, and the higher performance, the better > > longevity, and higher quality. > > > > Infrastructure capabilities (code to be > configured > > not > > programmed) grow in size as we move up in > > abstraction. > > At BPM level, 70% of code are infrastructure > code. > > > > Each level has different set of infrastructure > > capabilities. SOA capabilities are differnet > from > > that > > of BMP. I think that capability models at both > SOA > > and BPM are not elaborated and work on in the > > industry yet. > > > > Jerry > > > > > > > > Jerry Zhu <[EMAIL PROTECTED]> wrote: > > > > > > What I want to say here is to > > pay > > > attention to the > > > evolution of technology, different technology > > > capabilities address issues at different > levels > > of > > > abstraction. Using C++/Java code to do what > > BPEL > > > does > > > is like using Assembly to do polymorphism. > > > > > > The nature of development activities has > changed > > > from > > > 0's and 1's, to assembly, to procedure, to > OO, > > to > > > Service Orientation to BPM. The latest is > > graphical > > > design. they are not new ones replacing the > old > > > ones, > > > but should coexist, There are still 1's and > > 0's, > > > assembly, procedure, OO, and Services to > > implement > > > BPM. This is my preference, one may > implement > > BPM > > > using C and skip OO and SO. I think that skip > > some > > > of > > > the levels of abstruction may be quick to > > develop > > > but > === message truncated ===
