On 10/05/07, Jerry Zhu <[EMAIL PROTECTED]> wrote: > > > > > > > You said Architectural approach at the BP level. What > is your understanding of BP and its architectural > approach? There are three architectures at this level, > business capability, IT capability and data. Are > there any BPM folks who can comment?
I'd say that there is quite a bit at the business level beyond simply capability, there are goals, objectives, drivers, legistation, organisational boundaries and the like. Once you have that picture clear its time to then worry about the IT side and the data. > > We have talked much about Service level IT > capabilities. Business modeling as this level seems > not discussed much. I know, and it confuses me because I know that lots of companies, outside of the product vendors, actually do this sort of thing. You'd almost think that the only thing that gets any press or analyst support is the stuff with a marketing budget :) > > I agree with your "lipstick on the pig of IT" that SOA > is not fully utilized to its full potential. > > When you say "BP is not always strategic to the > business" I need to know what is your def of BP. > Non-strategic areas of business is, in my vocabulary, > not BP but other types of processes that may not be > suitable for the use of SOA. Sales for example, I've worked with lots of sales people and I've not yet seen a consistently executed business process for Sales. There is a measurement process which is created by management and by the accountants but that isn't actually the sales process. Forecasting is another critical area in lots of businesses that can't be modelled effectively using processes. Planning is another non-process area, think about mapping out the layout of a retail store, it isn't really a process exercise its a goal driven exercise. Back in finance, accounts, HR and the like however (as with CRM) there are a whole raft of processes that are part of the basic operation of the business but which have nothing to do with its strategic goals. > > I agree that IT has not served business as desired up > to date. As IT truly moves up in its levels of > abstraction, I believe that there will be better > business and IT aliance. Now there I agree with you completely... > > Jerry > > --- Steve Jones <[EMAIL PROTECTED]> wrote: > > > On 10/05/07, Jerry Zhu <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > > Steve, I do not blame you about Business Process. > > It > > > bogs down what is BP. I bet ten people will say > > ten > > > versions. I define BP as "a set of related tasks > > to > > > accomplish a goal. it begins and ends with > > customer to > > > deliver a product and service." There are other > > > processes like management process, support > > process but > > > they are not BP. So BP is by definition customer > > > facing. Does that kind of BP cover your > > "marketing > > > facing services"? > > > > As the implementation bit yes, but the key bit for > > me is as you said > > "begins and ends with a customer" and its that bit > > which the customer > > cares about. I'm not saying BP doesn't exist, just > > that it isn't as > > important as the current tech community think and > > that it is the > > implementation approach rather than being the > > architectural approach. > > > > > > > > I don't understand why people mean SOA IT only, > > SOA > > > is as much IT as business at the same time. The > > scope > > > of SOA units are not customer facing but are > > about its > > > implementation. There might be alternative > > > implementations. But SOA beneifts have been > > talked > > > well enough. > > > > What I mean is that there is a, large, body of > > people who look at SOA > > as being the lipstick on the pig of IT, its a thin > > veneer (ala EAI, > > but now with added XML and HTTP) for exposing that > > IT estate. > > > > This is the SOA that is IT only, and its not much > > better than the > > previous generations of IT and certainly isn't a > > game changing exercise. > > > > > > > > BP serves the purpose of cusotmers which is > > strategic > > > to the business. SOA serves the purpose of BP > > hence > > > operational. The former's IT aspect is BPM the > > > latter's business aspect is business subprocess. > > > > BP is not always strategic to the business, infact > > I'd almost be > > inclined to say that BP is dominant in the > > non-strategic areas of > > business (e.g. backoffice). SOA 4 IT serves the > > stack based view of > > BP(M) but it is certainly possible to model at a > > higher level of > > abstraction than either SOA 4 IT or BP(M) which is > > the Business SOA > > that I bleat on about. > > > > > > > > So SOA is not just dust but business capabilities > > > enabled by IT and made accessible and reusable by > > IT. > > > > Which to me is the dust, because we've been there, > > done that and > > failed a whole load of times. CICS was the same, > > MVS (IIRC) was the > > same, CORBA was the same, EAI was the same, DCOM was > > the same and now > > we have WS. > > > > For SOA to actually matter it must change the way > > people think, and > > neither BPM nor SOA 4 IT is capable of achieving > > that. > > > > Grumpy Steve > > > > > > Jerry > > > > > > > --- Steve Jones <[EMAIL PROTECTED]> wrote: > > > > > > > I have to disagree here Jerry, Business > > Process is > > > > a long way away from being the only way that > > value > > > is _generated_ within a business. When people > > > > interact with businesses they tend to interact > > at > > > > specific points, these tend to be marked, and > > indeed > > > referred to as the "market facing services" of > > > > the organisation. > > > > > > > > Viewing SOA as just about the dust at the edges > > > > misses the real point of SOA > > > > which is that by using services to model > > _business_ > > > > you can understand what > > > > different approaches are required in different > > area. > > > > BPM and SOA, if driven > > > > from a technical perspective, will fail to > > deliver > > > > any real benefits to > > > > organisations. Technology is a secondary > > concern, > > > > the main goal is changing > > > > the way people think about IT. If SOA just > > aims to > > > > be the dust while BPM is > > > > the business then it will be just as successful > > as > > > > BPM was _before_ SOA and > > > > as EAI was in controlling that dust. > > > > > > > > > > > > > > > http://service-architecture.blogspot.com/2007/05/soa-isnt-about-technology.html > > > > I tried to sum up what I mean in two pictures. > > > > > > > > Steve > > > > > > > > > > > > On 07/05/07, Jerry Zhu <[EMAIL PROTECTED]> > > wrote: > > > > > > > > > > I see some conceptual confusion here. > > Business > > > > > process outcomes in the form of > > produce/service > > > > > delivered is not the same as SOA services. > > Now > > > > here > > > > > product/service refers to customer value > > created > > > > and > > > > > delivered. This value has nothing to do with > > > > > procedures or activties but is measured by > > the > > > > > external customer that varies from customer > > to > > > > > customer. Customer (external) value is > > created, by > > > > > definition, only by business processes not by > > > > smaller > > > > > granualities such as subprocesses, procedures > > or > > > > > activities. > > > > > > > > > > These smaller units can be captulated into > > SOA > > > > > services to be assembled and reassembled to > > form > > > > new > > > > > business processes. Therefore in this > > context, SOA > > > > > service is a function not a intangible value. > > > > > > > > > > I think this distinction is not only > > politically > > > > > correct but also convenient both in business > > and > > > > > technical sense. > > > > > > > > > > Jerry > > > > > > > > > > > > > > > --- "Shashank D. Jha" <[EMAIL PROTECTED] > > > > <shashank.dj%40gmail.com>> > > > > > wrote: > > > > > > > > > > > Thanks for a insightful article. > > > > > > > > > > > > But still it fails to convince me that --- > > > > > > Quoting from your article..start > > > > > > Thus, SOA may be viewed as a technical > > > > architecture > > > > > > built around an > > > > > > enterprise business model, not around > > isolated > > > === message truncated === > > > >
