Yes, I noticed when I was reading the article, that you hadnt written it. However, I posted the question in an attempt to discover the answer from the combined experiences of the group members.
Thanks for sharing the article anyway. Cheers G P.S. Moderator, if you are getting this, please advice how I may resolve lost posts to this group. Thanks. --- In [email protected], "Gervas Douglas" <[EMAIL PROTECTED]> wrote: > > Gautham, I would like to point out that I did not actually write this > article - it is way beyond my modest capabilities! Perhaps the > logical conlusion of what you write is that CEOs should invite back > all those old managers who were dumped because they were > computer-illiterate technophobes. These could be just the > clear-thinking, jargon free, down-to-earth people to sort out the > whole mess... :) > > Gervas > > --- In [email protected], "Gautham > Kasinath" <gautham.kasinath@> wrote: > > > > Excellent article, Gervas. Quite a comprehensive article, which if I > > may bottom-line it as: > > SOA must be business driven and not IT driven. Further, Model SOA to > > the business but not the IT tech. > > > > If I bottom-lined it right, there arises one question. How does one > > marry Business and programmatic logic, in the context of SOA. Often, > > businesses have many applications independently developed, pre-SOA > > road map. Businesses have been trained to think and act the way IT > > dictates, rather than the other way around. So the challenge will be > > to change the mindset of the businesses, to think independent of the > > programmatic logic and have the systems and processes work as > > businesses dictate. Is there a magic potion to do the same? > > > > The above is typically the problem that I come across amongst my > > colleagues, at work. While the SOA road map is drawn and everyone is > > excited about it, my concern is that the elements on the road map > > are not sufficiently future-proof. > > > > What are your thoughts on changing mindset from process driven > > businesses to business driven processes, in the context of the > > question mentioned above? > > > > Cheers > > G > > > > --- In [email protected], "Gervas > > Douglas" <gervas.douglas@> wrote: > > > > > > > > > > > > ZapThink > > > > > <http://www.zapthink.com/styles/Internet_Market/images/zapthinkheader > > .jpg> > > > > > > > > > > > > > > > > > > > > > Business Modeling and Outside-In SOA > > > > > > > > > Document ID: ZAPFLASH-20061012 | Document Type: ZapFlash > > > By Jason <mailto:jbloomberg@> Bloomberg > > > > > > Anybody who has ever attempted to teach computer programming to a > > room full > > > of tech novices knows that some people easily get it, while others > > simply > > > don't. There's something about the basic "do this, make a > > decision, then do > > > that" execution flow of any program that is comes naturally to > > some, while > > > other people simply don't seem to be wired in such a way as to > > make sense of > > > such algorithmic thinking. As it happens, the algorithm-resistant > > population > > > is every bit as clever as the programming-friendly group; it's > > just that > > > they think differently about the behavior of systems and thus > > choose to > > > represent them in different ways than their more technical peers. > > > > > > The underlying observation here is that human beings are > > marvelously adept > > > at representing arbitrarily complex concepts with a wide range of > > different > > > kinds of models. In fact, our innate ability to model reality is so > > > pervasive in our day-to-day lives that the modeling process tends > > to fade > > > from our awareness. Nevertheless, whether in business or in any > > other aspect > > > of our lives, we are actively dealing with the complexity that > > surrounds us > > > by building internal models that represent various aspects of > > reality. > > > Furthermore, the types of models we use are amazingly diverse, as > > each of us > > > leverages different types of models for representing the full > > spectrum of > > > experiences we encounter in our lives. > > > > > > As organizations look to Service Orientation to provide best > > practices for > > > leveraging information technology (IT) to provide agile resources > > for the > > > business through the power of the Services abstraction, the > > ubiquitous, > > > varied, and subtle nature of the human ability to model complex > > situations > > > becomes a central concern. After all, the abstractions that > > Services > > > represent are a type of model themselves, as are all the ways that > > people > > > think about using Services in their business processes. > > Furthermore, the > > > dichotomy between people who are comfortable thinking > > algorithmically and > > > those that aren't resonates well beyond the classroom, with the > > > algorithmically inclined leaning toward careers in IT, while > > people who > > > prefer other types of models gravitating toward business roles. > > > > > > This natural division of aptitude presents a challenge for any > > organization > > > implementing Service-Oriented Architecture (SOA), because Service > > > Orientation brings together these disparate ways of thinking about > > modeling, > > > and requires IT to support the variety of models that business > > people > > > prefer. Indeed, technical approaches to business modeling have > > fallen short > > > of addressing the needs of business people who tend to think in > > > non-technical terms. As a result, learning how to accommodate the > > different > > > ways that people in the organization think about both business and > > > technology is a critical best practice in the Service-oriented > > architect's > > > toolbelt. Without this understanding, the business is unlikely to > > extract > > > the value and flexibility from the SOA implementation that they > > desire. > > > > > > Understanding Models in the Business World > > > Ask an average cubicle dweller who's not in IT to break down what > > they do > > > every day into its most basic elements, and you're likely to > > solicit a list > > > of human interaction-based activities that move information around: > > > conversations, meetings, sending and receiving communications, > > reading and > > > writing, and the like. Knowledge workers might throw in activities > > like > > > analyzing or evaluating. Few business people, however, will reply > > that they > > > spend their days executing business processes. > > > > > > From the IT perspective, however, if you define a business process > > as "what > > > a business does," or even as "a set of activities intended to > > achieve a > > > business goal," then all the various activities that our cubicle > > crowd > > > undertake fall into the category of executing business processes. > > In fact, > > > ZapThink frequently espouses the perspective that the Service- > > oriented > > > approach to business process calls for flexible business processes > > that > > > respond to the way humans work, rather than processes that > > constrain humans > > > to work the way the systems want them to work. The problem is, the > > various > > > models IT uses to represent business processes -- flowchart-based > > > orchestrations, flexible choreographies, defined flows -- are only > > a small > > > subset of all the useful models that businesspeople might use to > > represent > > > the way that they understand how the business actually works. > > > > > > In fact, businesspeople have a rich, varied set of models for > > representing > > > how they move information around: conversations, messages, > > documents, > > > spreadsheets, Web interfaces, mind maps, flowcharts, agendas, > > schedules, > > > calendars, and other loosely structured forms of information > > representation. > > > To be truly successful with SOA, therefore, IT must support these > > multiple > > > approaches for representing and exchanging information, instead of > > > shoehorning business operations into an IT-centric representation > > of how > > > techies think the business is supposed to work. > > > > > > Taking Business Models to the Next Level with SOA > > > Models, of course, are core to architecture, and SOA is no > > exception. > > > ZapThink's SOA Metamodel consists of a number of different models, > > including > > > the business model, which represents the requirements of the > > business, the > > > Service model, which represents both the Services in production as > > well as > > > the requirements for new or changed Services, as well as > > implementation > > > models that represent the underlying technology that supports the > > Services > > > abstraction. Of these, the Service model is what makes SOA unique, > > and > > > implementing the Service model properly is the essence of > > effective SOA. > > > > > > The best way to implement the Service model is through metadata: > > Service > > > contracts, policies, Service composition logic, and other metadata > > that > > > represent all the salient aspects of existing or required Services > > and their > > > use in the organization. Metadata are the appropriate vehicle for > > such > > > models, because metadata support declarative representations of > > dynamic > > > configurations. This declarative nature of metadata, in fact, is an > > > essential enabler of SOA, and one of the primary reasons that the > > prevalence > > > of XML has provided the raw material that characterizes today's SOA > > > initiatives. > > > > > > You might assert that the opposite of "declarative" > > is "programmatic," where > > > metadata implement declarative configuration while executable code > > supports > > > programmatic logic. The context of the variety and subtlety of the > > human > > > reliance on models, however, blurs the distinction between > > declarative and > > > programmatic approaches. Clearly, if you're writing Java or C# code > > > manually, you're behaving programmatically, while if you're > > picking options > > > off of pull-down menus on a Web page, you're behaving > > declaratively. But > > > what if you're using an XML-based programming language like > > > <http://www.waterlanguage.org/> Water? The Web Services Business > > Process > > > Execution Language (WS-BPEL, or BPEL) is similarly an XML-based > > execution > > > language, as its name suggests. > > > > > > Furthermore, a business user may be interacting with a fully > > declarative > > > interface, but might type in some simple JavaScript or Visual > > Basic in a > > > field to express some business logic. Indeed, while it's possible > > for a > > > declarative tool to support pull-down menus that can duplicate, > > say, a line > > > of JavaScript, just how important is it to avoid typing in a > > simple script? > > > Furthermore, it's possible to argue that text-based programming > > languages > > > are themselves a form of metadata that represent the underlying > > bytecode > > > that the appropriate platform can execute. > > > > > > Lest we allow this discussion to devolve into an unproductive > > battle over > > > declarative vs. programmatic approaches, it's important to realize > > that both > > > techniques are models -- and furthermore, represent only two among > > many > > > different models people use for modeling the flow of information > > in the > > > organization. Some people prefer to think programmatically, others > > favor > > > declarative thinking, while still others would rather use a > > spreadsheet, > > > rules engine, calendar, email client, or some other > > representation. Is > > > typing a formula into a spreadsheet cell programmatic or > > declarative? > > > Regardless of your answer, the point is that it doesn't matter, > > since > > > spreadsheets effectively represent certain information-related > > tasks > > > consistent with popular, well-understood models for such tasks > > that the > > > business uses every day. > > > > > > The ZapThink Take > > > There is an essential lesson for the architect here: design is an > > outward-in > > > process, not inward-out. All good architects begin with humans and > > what > > > they're looking for from the systems the architects are designing. > > Since > > > Service Orientation requires an enterprise perspective on the > > interactions > > > between business and IT, it's essential for the Service-oriented > > architect > > > to be able to wear the hat of a business architect, and consider > > all the > > > various models that the business is apt to use to represent the > > capabilities > > > both of the business and the IT that serves it. > > > > > > Furthermore, there is also an important lesson here for technology > > vendors > > > as well: SOA tooling must be as diverse as the business users who > > wish to > > > use it. People may utilize any number of different tools that > > leverage > > > numerous models to take advantage of the Services their SOA > > provides. Gone > > > are the days where tools vendors can manufacture only hammers, and > > expect > > > their customers to recast all their problems as nails. By > > abstracting the > > > interaction between business and IT, the business now expects IT > > to take > > > care of business however the business sees fit, and not vice-versa. > > > > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
