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" <[EMAIL PROTECTED]> 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/
