This is a blog post in response to Todd Biske's posting on "The End of the Application" which can be found at the following URL.
http://www.biske.com/blog/?p=347
******************************************************************************
I am in complete agreement with you Todd, about needing a retirement plan for the term "application"!!! I share your sentiment about how this ubiquitous term reflects not only the siloed solution that gets built but also in how this term influences the way in which the business need is translated into requirements. Case in point is the way in which I have heard business analysts phrase their questions to the end-user. For example, "How do you expect to act on the information the application provides?" as opposed to asking "How do you or your user community make decisions based on this information?" OR "What is the business context (business rules, policies,regulations etc.) that influence the information?". The business analysts sould divorce themselves from thinking about the application as the "sole repository" of the information and it's current limitations. Analyzing the business user needs and the decision making process might help them discover that these business rules may have already been implemented elsewhere and that the "application" is but one component needed in delivering the targeted business capability. Sadly,this is not the case.
Part of the reason for gravitating toward point solutions and monolithic deployments is the sense of control the solution owner has on the entire solution stack and the confidence factor of knowing that a customized deployment has a better chance of meeting the response time SLAs. It is my hope that the availability of robust standards based deployment platforms may help resolve some of these latent fears. The key however is to recognize that the usage of the term application does influence the final implementation of the solution. Given this, there is ample justification for doing away with the term "application" as it may be too limiting in the realm of today's highly interconnected enterprise.
Doing this may lead to the required behavior change that is needed to move away from the creation of monolithic applications. As suggested by you Todd we may need to be more conscious of the term we use and this could be a simple matter of using a prefix to the term application or it may be that we have to throw the term away altogether. I propose using a prefix of "composite" to qualify the term application to get this desired change in behavior!!
The term application should be semantically equivalent to "applying" a
unique business context to the usage of a common asset such as a business service, legacy system or a business process. This "application" (note,the verb) of value-added business context is focused on delivering a crucial business behavior that offers competitive advantage to the enterprise. With that definition in mind, the term "application" may get a lease for life when used within the purview of the concept of "composite application" that suggests "distributed solution assembly" instead of "monolithic solution creation". Composite applications are mechanisms that help deliver novel business capabilities that are typically translated to"novel" assembly of reusable business services where by the composite application layer performs business context value-addition.
This assembly of business services within a composite application (as opposed to the creation of a monolithic application) enables the enterprise to realize "speed to market" gains from SOA. It also enables an enterprise to move to a model where the enterprise obtains base business services (off the shelf or SaaS style) and uses the composite application layer to apply the enterprise specific business context with the idea of offering distinct flavors of service offerings; thus moving away from the "creation" of solutions to "provisioning" of solutions. (It is worth noting that composite applications are not just deployed in the business layer but also
in the presentation layer in the form of Web 2.0 style mashups.) Finally, I feel that the only way we can move away from the mode of "monolithic point solutioning" to a mode of "assembling solutions" is by making the move to the concept of "composite application" as it breaks the existings emantics associated with the term "application". Following this mindset switch we may be able to completely replace this term as knowledge workers develop a comfort level in both the efficacy of "assembling solutions" at the same time that the vendors build up deployment platforms to help IT meet the stringent SLA needs that are demanded by the business.
***********************************************************************************
Practitioners observations and view on the best practices, key learning on the fast changing landscape of technology and architecture. - Strategic User of Information Technology - Cloud Computing - Big Data
Subscribe to:
Post Comments (Atom)
Key Learnings - Using EDA to implement the core SOA principle of "loose-coupling"!!!
A lot has been said about how SOA and EDA are unique "architecture styles". It seems like only one or the other architectural prin...
-
The purpose of this blog is to get some validation for how I look at Business Processes vs. Business Services. In simple terms, I differen...
-
A lot has been said about how SOA and EDA are unique "architecture styles". It seems like only one or the other architectural prin...
-
One of the key ingredient for success is clearly defining the roles and responsibilities within IT. There are multiple stake holders in IT w...
No comments:
Post a Comment