Enterprise Solutions versus Applications

Posted by Tom Dwyer on Tuesday, February 2, 2010 - 13:46

Rate this:
Total votes: 0

Business applications are the root cause of today's siloed nature of enterprise IT. The use of SOA for building enterprise applications preserves all the drawbacks of today's application-centric culture. What is needed is to use SOA for building enterprise solutions. Has anyone used SOA to build enterprise business applications? Did it meet your needs?


Login or register below to comment on this discussion.
Pierre Gagne
posted 3 years 36 weeks ago
In my mind, there are business SOA and technology SOA enterprise solutions. I am a proponent that business SOA enterprise solutions provide a good way of delivering integrated business solutions. In order to achieve this, you need to develop a business architecture. We only work with insurance and wealth management clients. We have not seen clients building SOA applications without a business architecture or at least a business architecture framework. We have seen a number of clients that did not have any reference models to build SOA applications. So to assist our clients that have nothing or want a start to build an enterprise business architecture, we provide them with a FREE capability map and an enterprise business architecture framework for the insurance and wealth management industry. It is called Panorama 360 and it can be ordered Free of Charge for the financial industry at www.InsuranceFrameworks.com. If you want more details, write to me at Pierre.Gagne@insuranceframeworks.com.
boris billereau
posted 6 years 19 weeks ago
This is a wide question! There are two Dimensions in the life. A global and generalization of needs and the specialization of needs. the Enterprise has need both dimensions: the Enterprise solutions and business domains applications solutions for each business domains (silos?). The second one uses the first one. The difficulty is how identify wich is ES and other BAS for each one. Silos are natural by this principle and is not incompatible with entreprise solutions. In fact, all is story of scope of application :-), First, an application is a solution, second an application can be either an entreprise solution or a business domain specific solution. Thrid, an application can be an enterprise solution, a enterprise solution can be an application. Ha the semantic. We just have to define the scope. Define application is difficult. Let's start from following assumption. An application is a use case. A use case is a couple consumer-provider. An application born from needs of use cases of some consumers using some providers. The notion of consumer and of provider is strong in all domains. A provier is a service. in the same manner, a service can be localised or generalized and the "ice on the cake" is that a specialized can be generalized, because the business domain service classified in his own domain can serve other business throught applications consumers (screens, services/process, etc). In resume, the big problem is the organisation of the synergie between the specific business domain and the enterprise solutions. Would not be the governence role? Is not a problem of OO or of services, this always has existed! This is a problem relative at the well known practice concerning the composition, decomposition, generalization, specialization and scopes. [Updated on 7/9/2011 10:14 PM]
Ulrich Gumgowski
posted 6 years 25 weeks ago
I think there is no "Enterprise Solutions vs. Application" because the classical enterprise solutions are build of applications - specially of historically grown applications. For me, building a "SOA" on a historically grown IT-Landscape seems to be not very effective because the real, deep value of servicing can not be utilized due to the deficiencies of the underlying applictions. Thats a money making machine for software providers. The real value of SOA comes naturally when there are NO applications at all - just a community of communicating objects - ideally business objects - which provide published services to be used in processes which in turn are controlled by rule engines. But then the "orientation" is convicted to be needless - the whole thing is no longer service ORIENTATED but service MADE - purely build on services provided by objects. By the way, for me the whole "orientation" reflects the human disposedness to inconsequence. What is object orientation? Either there are true software objects relecting real world objects - or not. In most todays business systems there are no tru objects - except in software build with truly object languages like Smalltalk combined with GemStone/S... Cheers, Uli
Patrick Conroy
posted 7 years 8 weeks ago
Tom Posted: "Business applications are the root cause of today's siloed nature of enterprise IT. " You feel the applications themselves are responsible for the silos? I disagree - the organization is responsible for the silos. The applications reflect the org. Tom Posted: "The use of SOA for building enterprise applications preserves all the drawbacks of today's application-centric culture." How so? SoA the protocol? SoA the design approach? SoA is a way of thinking; a way of designing a solution. Your sentence reminds me of an old maxim used in carpentry: "Tis a poor craftsman who blames his tools." Tom Posted: "Has anyone used SOA to build enterprise business applications? Did it meet your needs? " Yep, we're about five years past deployment into production. And to the last question, "Yep!"
George Ludgate
posted 7 years 11 weeks ago
This is crazy talk. Ever since the object oriented approach to building systems was adopted every analysis was an enterprise analysis and its implementation lead to an enterprise application. It was OO development that led people to realize that using it you are no longer creating an application but part of an expanding automaton of the enterprise – the role events discovered did NOT belong to the project that analyzed and coded them up – they were reusable. If OO development is the “cake” then SOA is the “icing on the cake” and business process models are the “frosting”. OO development gives you all the role events which make up a SOA – but it does not organize them in services as it does not capture the order in which role events are performed. Business process analysis gives you this order AND NOTHING ELSE. If you are surfacing data during a process analysis then your OO analysis or your information modeling step is not working. Doing BPM does not mean you develop code from it! We dropped functional analysis nearly 30 years ago as it does NOT lead to well structured software system – they are hard to change as the functionality has not been “normalized” – OO development added this feature. I agree with the BPMS comment. Every technology you adopt has some element of lock-in.
David Rubin
posted 7 years 12 weeks ago
you may be right, but I think the future you envision is a bit farther off than you think. My currently experience with multiple BPMS systems have shown them to be seriously prorietary, while at the same time prompoting their adherance to standards. Once excuse is there's nothing in the standards which prevents companies from using cusomt tags, which then can't be consumed by other BPMS systems. Further, while the security models of the different prodcuts look compatable, at the lowest level things like security tokens can still not be shared.
Mathew Newton
posted 7 years 13 weeks ago
The more I read and see via pilot projects the more I get the feeling that BPMS or similar systems are going to become the architecture for developing most business applications of the future. Most being the key word here as there are still appilcations that will benefit from other development paradigms. The beauty of BPMS and related systems are that they surface business data where it is needed in the organisation and when they need it. There is flexibility in improving the current implemented process by non-developers and there is the ability to add new applications/processes fairly easily depending on the existence and complexity of the data store/s involved. I see BPMS as one of the key services of a successful enterprise of the future.

Join the Discussion

Already a Member? Login Here:

Shopping cart

View your shopping cart.

Business Process Management Jobs

Editorial Directors

Gregg Rock
Gregg Rock
Editor & Founder

Andrew Spanyi
Editorial Director

Jeff Scott
Editorial Director