As a modern large company, is one ERP system better than hundreds of highly specialized applications which are service oriented? To provide a little bit of background, we are providing consulting for a client who wants to invest their resources in a monolithic ERP system which will manage everything! What are the pro's and con's of this approach?
As an application developer, I tend to believe that specialized well written and managed software packages tied together by a service architecture would out perform a monolithic approach.
What do you think?
As an application developer, I tend to
believe that specialized well written
and managed software packages tied
together by a service architecture
would out perform a monolithic
approach.
Maybe, but getting support for one system from one party is easier than getting support from multiple parties and making sure that integration works and keeps on working.
I think a more important question is whether to pick a general ERP or a custom fitted one. Whether the architecture is service oriented or monolithic is maybe is related, but also general ERP systems can be service oriented.
This almost feels like a traditional question on buy vs. build. I will try to lay out
some importan points.
If you clients has deep pockets only then can they viably maintain the high total
cost of ownership and complexity associated with developing and
maintaining custom-designed applications.
Off-the-shelf ERP solutions integrate the best business practices from a variety of
industries and incorporate these best business practices into your
client's operations which ultimately translates into bottom-line improvements.
Custom-designed applications provide the desired degree of functionality,
but their size and complexity require lengthy design, development, and
implementation efforts.
A good example that I can think of is Microsoft. Microsoft spent 10 months and $25 million installing SAP R/3 to replace a
tangle of 33 financial-tracking systems in 26 subsidiaries. As a result of the
implementation, Microsoft estimates annual savings at $18 million,
leading Bill Gates to call SAP "an incredible success story."
Hope this helps you think more broadly from all angles.
Related
We've been having a discussion at work over how widely used SOA is. We've been building our businesses processes using SOA for a few months now with varying degrees of success and the question came up about how widely used this architecture is. My manager believes that "most" of the big companies are using SOA and it is gaining steam among the industry, is cutting edge technology and everybody will doing it shortly. I argued that it seemed to be the new buzzword about 2-3 years ago and was never widely adopted.
Does anybody feel strongly one way or another?
Thanks.
SOA is an easy, standard way to write web services that other middleware (and user-space code) can use. If you need to integrate existing code/services with web clients or other middleware clients, its a good thing to consider.
You didn't mention much about what you're trying to accomplish or what technologies you need to integrate, but I have written Oracle SOA web services that are consumed by Android in the mobile sphere, Spring in the web sphere, and other Oracle SOA clients in the enterprise sphere.
All depends on what you're looking to do, but SOA is more of a concept - and a borderline standard for integration architecture, that presupposes any particular implementation.
I am the .Net specialist in a consultancy with many difference flavors of developers using many different languages and frameworks. Because everyone is pretty much trying to push their own agendas with our different clients in terms of what technology to propose, I'm constantly finding myself in the classic arguments with them all about "why" .Net may be a better technology solution for a given clients requirements.
Often time here, the debate comes down to the issue of performance. Usually the areas that are argued about here consist of costs, maintainability, and performance. I have a hard time arguing about cost because in general open-source technologies are usually cheaper, and although and can usual put a good word in for .Net in terms of total cost of ownership (It seems to be pretty easy to convince people that .Net applications have relative low costs for maintainability if the application architecture has been thoughtfully designed), we will really only push .Net here if the client understands and is indifferent about the costs associated with Microsoft licensing. In terms of maintainability, like I mentioned before, the other developers here realize how much a difference it can make when an application is thoughtfully designed. I have had around 8 years of experience programming .Net solutions and I'm pretty confident in my ability to present to a client all the features and tool sets that .Net provides to give an application a long, and easy to maintain life span.
So again, what it usually boils down to is an argument over performance. Up until now, I have worked for companies that already used Microsoft development technologies to developer their applications so while I have discussed performance with others in the past I have never been a position where I have had to convince performance. My other co-workers are always boasting about these different website that they go to that show improved performance for open-source web applications. This all being said, what I would like to know from everybody here is where do you usually go to get your information about how may some .Net web applications have out performed other technologies?
Thanks in advance for the advice,
-Matt
I appreciate the detail, though I must say I forgot your question at the end. =)
Anyhow, this is something that has certainly been on my mind in the past. There is always a conflict on what technology is the best. We all know on each side you will find zealots, so it's quite difficult weeding out the facts. Professionally, I've seen successes/disasters on both sides of the fence.
For you, since you have a vested interest in .NET. I would showcase success stories, such as ... (insert whatever big name site you want) Facebook, SO, etc. I'd also find stories where things went wrong on the .NET side and pinpoint the reason. Like you said, it is often poor implementation. I don't know how many DailyWTF stories I've seen with ASP.NET sites behaving poorly but it gets traced back to 1) Poor design 2) Implementation 3) Coding.
Once you have a solid show case to justify the technology you can then of course talk about your own past experiences. You need to qualify yourself as being able to avoid the same pitfalls that your stories exposed.
.NET loses in performance against C/C++. In general, it will win over Python, Ruby, and PHP in baseline performance. The static typing tends translates into faster native code. (There are exceptions, such as Python's hand-tweaked set() performance being faster than HashSets in .NET)
The difference might come down to things like apache vs IIS (and their respective caching configurations), database architecture, etc. Features than can be misused or misunderstood (ViewStates and large GridViews, or using large numbers of hidden WebControls, for example)
Depending on what type of application you are building I've found that performance is rarely an issue. All the technologies out there can perform well enough.
When debating .net versus java/ruby/python etc I usually try to point out other benefits of .net.
There was this one time my boss asked me why .net instead of others? He wanted to know because he could get a PHP programmer for cheap. As part of the report we wrote a simple web application in 4 different languages and the .net app ran the fastest by far. After that we solidified behind .net. This was when .net was new so none of us really knew it well. We came from ASP, PHP, Coldfusion and Java backgrounds.
If you are looking for .Net performance stories you can listen to this dot net rocks show
I'm starting to build a community website from the site up and my web framework will be Asp.net and Mysql.
I want to start planning some scalability into the infrastructure early because I'm anticipating high traffic when the site goes live.
Are there any case studies which you recommend reading where asp.net or mysql has been scaled and which demonstrates good scaling techniques?
I think it could be a challenge to find reference materials for that particular combination. Many .NET shops stick to SQL Server, and fewer use MySQL (at least at scale).
In general it would be appropriate to:
Follow general .NET practices for scalability. Weed out what is not appropriate for you.
Learn about database performance and implications of various design strategies such as denormalisation (when and why).
Consider out-of-process caching like memcached.
Review books on MySQL performance. Most of these are focused on UNIX platforms. Windows users may have problems applying some of these practices.
Read up on how other people are scaling their sites (Building Scalable Sites and The Art of Capacity Planning)
Consider how you might optimise your web design to be more scalable. Are you using AJAX? Work out what the impact of excessive polling may be etc.
Learn how to measure the performance of your application and database (starting points ASP.NET and MySQL).
Develop a plan for scaling your architecture (1 server to 2 servers, to multiple servers etc) so that you have some frame of reference for making decisions about building things in your system.
I only know of one really good resource to read case studies about scalability techniques and I am really surprised no one has mentioned it. High Scalability
There is so many examples of "out of the box" thinking that and different techniques for scaling that I think it makes a good read for anyone who is interested in the topic.
BrianLy said it best here:
"Develop a plan for scaling your
architecture (1 server to 2 servers,
to multiple servers etc) so that you
have some frame of reference for
making decisions about building things
in your system."
As a forum I frequent says, 'quoted for truth'. All of his points are excellent, but this one is a key point that many people overlook. It doesn't matter how scalable your code and database are if you are running on a creaky old server. The hardware may not be as important as your code, improving it beyond a certain point will give diminishing returns VERY quickly, but do NOT forget to get your hardware to that point. If you have crap hardware, or even good hardware but not enough of it, your site will bomb out.
For mysql scaling, you may find this interesting: danga livejournal
My company (a large organization) is developing a "road-map" for evolving their rather old, tangled confederation of systems to an SOA model. A few people are pushing hard for using Websphere Integration Developer and Websphere Process Server as the defacto platform for developing future applications...because they feel IBM is a stable vendor, the tools are made for the enterprise, they drank the "business agility" BPEL kool-aid, etc.
Does anyone have positive or negative thoughts on this platform? Do the GUI tools help eliminate monotonous/redundant coding...or just obscure things and make things harder to maintain? Basically, do the benefits justify the complexity?
My experience with the IBM Java tool set is pure pain. Days to install lots of different versions of different components all incompatible with each other, discover a bug in component A get told to update to see if it fixes, updating component A breaks component B and C, get told to update these etc.
I find Eclipse with out the IBM extensions far more stable and quicker and provides more features (as its stable versions are a couple releases ahead of WID/RAD).
I would advise against going the IBM way for development tools. As for process server I have less experience but the people in my team using it seemed to enjoy it as much as I enjoyed WID. not a lot.
So far I havent been impressed by any tools with the "SOA" and/or "BPM" labels on them. My "roadmap" would be very very iterative to see some results with the archetecture as fast as possible while trying to grab some of the easy fruits. That way you gain your feel for what works for you and your people.
I would never let any vendor push me anywhere in the "scuplturing" of the architecture.
I agree with other users complaining about WID. The only reason we are using WID is that a decision was made a while back to use IBM products across the board by our sales department.
That's right, our sales department made the decision to use IBM products.
Development has been painful and frustrating. We have lots of stability problems with Process Server, sometimes it doesn't want to start or shutdown properly. Yeah you can easily draw processes in the IDE, but most any toolset provides that functionality these days. It is nothing special or unique to WID or IBM. IBM is a few iterations behind mainstream.
There are plenty of open source implementations out there that offer great support. Checkout JBoss or RedHat, they are pretty good. If that doesn't float your boat, you can always use Apache tools.
Walter
Developers don't choose WID, WMB, or WPS. Managers do, because IBM is a "stable vendor".
Look at JBoss, or K.I.S.S.
WID/WPS is actually pretty simple. The original intention was for analysts and business people to "compose" services (DO NOT LET THEM DO THIS!) so the UI is simple and easy.
Most of the work will be in defineing and implementing the back end services which depending on the platform will mostly involve wrapping existing code in SOA service.
The most important thing to bear in mind is that SOAP is technoligy and SOA is an architecture and a state of mind.
There is a zen to a succesful SOA implementation. Its all about "business services", if you have a service that you cannot describe to a business user in less than six words you have done it wrong! Ideally the service name alone should be enough to describe the functionality of the service.
If you end up with a service called "MyApp.GetContactData" described as "get name, addresses tel fax etc." then you are there. If You have a service called MyAppGetFaxNoFromOldSys" described as "Retrieve current-fax-nmbr from telephony table in legacy system" you are doomed!
Incidently most of the Websphere tooling for WS* is pretty nice. But I would recommend the very wonderful SAOPUI tool from http://www.eviware.com which is very good for compsing/reading WSDL based messages and also function as a useful test client or server.
Do the GUI tools help eliminate monotonous/redundant coding...or just obscure things and make things harder to maintain? Basically, do the benefits justify the complexity?
As a Developer, I find the tools at varying levels of being bug free. 6.0.1 was a pain, 6.2 is so much better. But once you develop with the tool, there is minimal effort to maintain it. I develop in hours what java developers take days to do. It is also easy to maintain as changes can be made very quickly. I cannot answer your question from the perspective of an architect or a Manager but i would agree with comments of some others here.
Service Oriented Architecture seems to be more and more of a hot quote these days, but after asking around the office I have found that I seem to get many different definitions for it. How would you guys define SOA? What would you consider the official definition?
As Martin Fowler says, it means different things to different people. His article on the topic is pretty good although it isn't quite a definition.
http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html
It may explain, the difficulty coming up with a concrete definition.
Wikipedia: "A SOA is a software architecture that uses loosely coupled software services to support the requirements of business processes and software users. Resources on a network in an SOA enviroment are made available as independent services that can be accessed without knowledge of their underlying platform implementation."
SOA is not that new, but it has potential to achieve some amazing things. But the organization has to be ready for it: the business has to think in processes and that's the big problem
I'd go with:
Defining a series of stateless, client
agnostic business operations created
to be leveraged in multiple
applications.
An SOA design includes components (i.e., services) that can be used by code regardless of implementation (i.e., any OS or langauge). A single instance of a service may also be used by multiple applications, whereas, e.g., a DLL would have to be duplicated for each app and require the same implementation technology as the linking application.
Services in an SOA design are usually implemented as interoperable web services.
There isn't an official definition as Ryan mentioned eariler. However, I find Thomas Erl's view of the whole service-orientation quite well-structured and relevant. Here is the definition of SOA from his SOA Glossary (more):
Service-oriented architecture represents an architectural model that aims to enhance the agility and cost-effectiveness of an enterprise while reducing the overall burden of IT on an organization.
Thomas Erl is the author of many SOA titles most of them receiving endorsement from SOA vendors including IBM, Oracle, and Microsoft. The nice thing about his books is that they are as SOA vendor independent as possible. It means you learn more about service-orientation itself and less about some vendor's middleware that supports SOA.
I agree with all of the people that point you to Fowler on this. Basically it runs like this: service oriented architecture got a reputation as being good, so anything that people want to be associated with good they call SOA. In reality it has a lot of downsides and can create a Service Oriented Gridlock or Dependency Oriented Architecture.
Here's my go at a definition:
Service Oriented Architecture is a systems integration and code reuse approach where applications are dependent on connecting to services provided by other running applications across the network. This is distinct from component architectures, where software components are shared statically between applications in the form of libraries or SDKs, for example.
A clarification here - "Service Oriented Architecture is a systems integration and code reuse approach where applications are dependent on connecting to services provided by other running applications across the network."
I have a scenario where two j2ee applications have been integrated using event driven messaging. Here the above phrases of systems integration and connecting to services provided by other running applications across the network hold good. Can i call this SOA ?
The following principles would hold good here
1) statelessness
2) message oriented - loosely coupled infact de-coupled
3) extensible.
However, the following do not apply
1) platform independence - neither of the applications being integrated has been designed to work in a different platform.
2) The applications are plain j2ee applications which have not been designed with all soa concepts.
I attempted to define SOA in one of my blog posts. Here's an excerpt...
For years it's been standard practice to separate functionality into functions, classes, and modules. The idea has always been that these smaller, highly specialized components are easier to share and maintain than monolithic blocks of code.
Functionally, SOA is not much different. The goals are the same - reusability and easy maintenance. The biggest difference - in the case of a web service SOA - is that the shared library included in your application is replaced with an HTTP call.
Here's a definition for you:
SOA - Software Over Architected. The inclusion of pointless, over-bloated, functional interface framework called an architecture in a pretty web site with a 3d graphic folder flying from one side to the other where "dir /s > a.txt | ftp -s:upload.ftp" did the job.
Software components are not bricks, cannot be generalised by common functional patterns and architecture emerges in the enterprise from good practice, not good design. Software isn't architected, it's engineered.
SCRUM ON!