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 > > miss future advantage such as reusability or > > agility > > or ability to change. For example if we build > > service > > using COM objects or Java beans, we could reuse > > them > > to implement new services instead doing > everything > > from scratch. > > > > Jerry > > > > --- Todd Biske <[EMAIL PROTECTED]> wrote: > > > > > As always, I separate out the technical issues > > from > > > the non-technical > > > ones. From a non-technical perspective, I > don't > > > think you'll get the > > > full benefits of SOA unless you're also > thinking > > > about business > > > processes. From a business standpoint, they > are > > at > > > worst > > > complementary, and in my opinion, should be > > treated > > > as one in the > > > same. We hear a lot about BPM being the > business > > > thing, and SOA > > > being the IT thing, and I think that's an > > artificial > > > separation. > > > > > > As for whether or not a process engine is > needed, > > I > > > don't think any > > > piece of technology is a "must." If an > > organization > > > doesn't have a > > > BPEL engine, what's the alternative? Probably > > > writing Java or C# > > > code. Why would it make sense to use a BPEL > > engine > > > instead of > > > writing code? The tools that I've seen all > > leverage > > > graphical > > > designer, which theoretically could be far > more > > > efficient for > > > building certain things than writing code. > That > > > comes with a > > > flexibility penalty, however, in that there's > > going > > > to be some logic > > > that just isn't well suited for it. If you > find > > > yourself writing > > > custom actions in Java, you should asking > whether > > or > > > not the whole > > > thing should be in Java. If the custom action > > has > > > broad > > > applicability, such as a custom integration > > adapter, > > > then it may not > > > be such a bad thing, but if it's only used by > > this > > > process, you've > > > probably just negated the time-to-develop > > benefit. > > > > > > Another reason touted for leveraging BPEL is > time > > to > > > change. > > > Theoretically, if it's faster to do > development, > > > it's faster to > > > change it. There's two questions to ask here: > 1) > > > Will the process > > > change? If the process changes infrequently, > > then > > > it really doesn't > > > matter. 2) What type of changes occur? The > > change > > > may not even be > === message truncated ===
