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