SOA/BPM: death of applications and AD as we know them
Application Development (AD) is approaching two dramatic changes: the death of applications as we know them and the death of application development projects as we've known them.
Death of applications as we know them
As service orientation becomes more normal for architecting systems, the very nature of an application begins to change. In the past, applications have been defined by the container that comprised their structure. This container included user interface, navigation through screens, embedded logic/data and management of the system. As SOA takes hold, the use of a modular set of software services explodes the application container into a loose set of business components that work together to provide application functionality. These modules are no longer held together through the application container alone. They are now tied together through policies, interfaces and a set of interoperable standards. A place from which a next-generation container could originate is buried within an obscure specification called JSR 208 or JBI. Within the JBI spec, constructs known as composite service descriptors (CSDs) consolidate metadata ,such as process models (through BPEL maps), orchestration, XSLT transformations for data to be passed, WSDL endpoints for the services, plus additions such as policies and business rules. The CSD construct and concept will be the most important piece of JBI. In many ways, CSDs can be viewed as the "applications" or "solutions" in a world of services. As next-generation application descriptors, this concept will impact applications — specifically at the point known as composite applications and service-oriented business applications (SOBAs). The CSD has the potential to become the orchestrated set of services that solves a particular business problem — ultimately applications need to map to business issues. Monolithic application becomes a loose set of services orchestrated (often dynamically, in real time) into a meaningful business service. This brings in critical challenges: definitions of development and runtime environment are changing ad hoc; a line between development and runtime environments is disappearing; technological platforms could be any; business users insist on being independent from a particular vendor; agility (that is, flexibility and speed) of ad hoc changes becomes paramount.
Death of AD as we know it
Our primary goal is to make AD cheaper, faster and better. Unfortunately, the nature of manual human labor and social, cultural and economic (that is, human) obstacles stand in the way of reaching that goal. The cost of cheap AD labor is limited by socioeconomic factors: Cheap places are cheap only temporarily. Cultural and language differences and geographical distances make offshoring less cost-, quality- and time-effective. A large percent of AD should be done on-site in the U.S., where offshore developers should be paid prevailing U.S. salaries. Speed of AD is limited by human nature. People can produce code no faster than they can type. People's multitasking abilities are limited. People can speedily handle only a limited number of variables. Julius Caesar, as chronicles tell, could handle seven tasks simultaneously. Even if you plan to hire Caesar-like workers, it is unlikely that you will find many, or that you will be able to afford to pay them "imperial" salaries. Quality AD products can be delivered only when processes, platforms, technologies, workforce and governance have been clearly defined. That is why we insist on detail service-level agreements; deviation, especially ad hoc deviation, from pre-defined parameters crushes our plans and results in late and overbudget delivery. Solutions to such problems cannot be found in manual-labor improvements, but in labor automation. Cost of "software machines" that automate AD process hardly can be beaten by manual labor. Speed of machines greatly exceeds that of manual labor. Machines' multitasking capabilities and manipulated variables are practically limitless. Quality can be achieved even when definitions of development and runtime environment is changing ad hoc. Although manual AD has been exhausting human capabilities (now reaching their limits), for machines, this is a way of "life."
Source: Gartner IT Expo
Technorati Tags:
SOA,
BPM