• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (8)

1 localhost commented Permalink

Cant agree more!The order should be (a) Architecture, (b) Software development life cycle capabilities, and then (c) services orientation....

2 localhost commented Permalink

Excellent questions that are well articulated. We in IT have been struggling with these in one form or another since Parnas wrote that breaking systems into parts was a good idea. The parts have changed names but the idea is steadfast. He also came up with some criteria for decomposing system into modules in 1972. I think these still work pretty well. In fact he once told me the design of software is relatively easy, documenting it properly is the difficult bit. We can design a system that will elegantly solve the issues above. But to my mind we have yet learn how to address the issue of effectively documenting the solution.

3 localhost commented Permalink

I appreciate your entry as it cuts to the heart of the issue without offending IBM. However, I'm a little worried about all the marketing hype surrounding SOA, pitching essentially a silver bullet to the CXO's for all their IT problems.

From what I've seen of IBM's SOA marketing materials, rarely does it mention sound software development methodologies as a foundation of SOA. Instead, I see lots of colorful diagrams (usually on Powerpoint) demonstrating flexible IT environments, which can support rapidly changing business requirements.
It is a very high-level black box. Magical even.
As a software developer, it's very hard for me to swallow. It's akin to generals giving high level details of war plans, with the soldiers on the ground doubting those plans.
Please tell me I'm missing something and that SOA deserves the hype.

4 localhost commented Trackback

The problem (IMHO) of SOA's (perhaps more of the hype of SOA's) is that it is the child of Web Services hype. Thus, when we try to promote sound SOA architectures there is often the implication that the solution must be a web service architecture. And people do want web services because they will automatically "fix" their problems of interoptability.

While I agree that these technologies are exciting and will fix a lot of problems, the reality is never as neat and clean as the hype.
My problem (from the point of view of an application developer) is that web service symantics and infrastructures are often not appropriate for the application domain, or are not well implemented by foundation technology providers or are still evolving. The result is that ISPs have to coerce their applications to fit the web services mold or they are not able to sell product, but by doing so, they become part of the snake oil travelling show.

5 localhost commented Permalink

I agree that architecture provides the solid foundation of any solution, but what is it in the Snake Oil hype that attracts people to Snake Oil sales people in the first place? The need to solve a problem!

To focus on the foundation first is like using the foundation of a 100 story skyscaper for a 2 story 5 bedroom house. Let the users' goal dictate the solution, hence architecture.
I think the problem is there are many well known architecture patterns and not enough well know solution patterns. Architecture patterns, like SOA, are only a part of the solution pattern.

6 localhost commented Trackback

I do not think CIOs are in more danger of snake-oil vendors now than they have always been. In the end, the business areas of the companies do not need SOAs, OO or anything, but robust functionality, and CIOs not able to deliver it just are selected out.

In theory, it is not services who "allow you to send and receive semantically rich messages through firewalls" - this is for *web* services. In theory, SOA is about any kind of service, not only web services. In practice, I think all of the benefits and hype of SOA have its foundations in the interoperability provided by HTTP, XML and WS-* . This is what makes the most difference now, compared to OO.
Next difference, it is true: SOA comes with an architecture, while OO did not. Although nobody agrees yet in which one exactly. Most people lean towards an ESB-centric one, even though still they do not agree in what an ESB is. But they will, in time.
And other features like governance, methodologies etc are just as they have always been. And indeed many software vendors are also actively addressing these areas, being IBM one of the most paramount ones in doing so.

7 localhost commented Trackback

How about going from A (architecture) to B (business)? I thought that in the end (or in the beginning), SOA has to be about business agility--the ability to rapidly react to changing business requirements--by removing the rigidity of the underlying technological infrastructure.

Maybe the snake-oiliness of the current state of the market has to do with the fact that: (1) SOA is just an enabler for business transformations; (2) with or without SOA, business transformation is a complex thing; (3) people haven't really figured out the way to go from B (defining business objectives) to A (creating the architecture for it) while benefiting from SOA.
I agree that there are a lot of good technical questions about SOA that remain to be answered (as you've listed in the post), but I also think there are a few fundamental business questions that remain to be expressed about the subject that are even more critical.

8 localhost commented Trackback

Dear Grady!Thaks for your questions, they are so valuable for my researches!

any way,
In these times, the incongruity which exists between the business processes and the technologies is one of the most well-known challenges which the people looking for that, whether the business process maturations would impact the technologies developments or the technological evolutions impel the business processes to be full-grown and fine-grained.What the people can look and feel without a doubt is the ratio of the technology growth, especially in Information Technologies.The people couldn’t measure without difficulty the process maturities, Instead of that; they can touch the time and cost consuming, and the quality of the reactions in the environments.Since the computers are created, just three concepts have being developed: Infrastructures, Data, and Functions.In the first era of the centralization (Mainframe era); the nations were specified by the Countries, the relations between businesses were at the Participation level, trading was mutually between the businesses on behalf of the governments, distributions of the information were restricted to the countries’ borders, knowledge was locally, and focus in the cyberspace was on the Infrastructures.In the second era of the centralization (Web era); the nations are specified by the Unions, the relations between businesses are at the Partnership level, trading is partially mutual and partially through the exchanges and marketplaces between the businesses with supervision of the third parties, distributions of the information are being controlled to the union’s borders, knowledge is partially local an partially global, and focus in the cyberspace is on the Data.In the third era of the centralization (Grid era); the nations will be as the Global Village, the relations between businesses will be at the Collaboration level, trading will be in the public cybermarkets for the businesses on administration of the UNO, the information will be distributed in the globe, knowledge will be globally, and focus in the cyberspace will be on the Functions.
And, I believe that SOA is being matured as a strategy to represent the Functions by way of realizing and adopting the future and new change requirements!
That is the tonality of my Dissertation.

Add a Comment Add a Comment