As highlighted recently on ZDNet, 48% of CIOs will be looking to actually start using their SOAs to connect to external partners this year. Unfortunately, we've been building landscapes of Web services for quite a few years now and for many, the tipping point for SOA adoption seems as elusive as ever. The techniques being used in the Web 2.0 world for viral adoption, network effects, community co-develpoment, the use of Ajax and widgets, turning applications into platforms, and even the outright convergence of the ideas of SOA and Web 2.0 are increasingly seen as hitting on the "right" mindset for building systems that users (and developers) will embrace en masse. The eleven ideas:

• Make services consumable in the browser.
• Consider syndication over "service-izing."

  The browser is an important consumption point but so too are the growing syndication ecosystems of which the blogosphere is the largest example. More and more tools are willing to consume RSS and ATOM, often in preference to SOAP, including the forthcoming version of Vista where syndication-friendliness is a core value. Carefully consider offering your services in RSS form or even ATOM, which has a two-way REST model. This will further increase consumption scenarios and therefore adoption. Content syndication is growing into a very potent force inside and outside the enterprise and plugging an SOA -- strategically or tactically -- into one of these ecosystems has terrific upside potential. Not every SOA service can or should be converted to a syndication model, but if you aren't considering this option with each service you create, you should be; there are tens of millions of RSS feeds available today, starting from zero in the beginning of 2003. How many SOAP services presently exist worldwide? Only a tiny, tiny fraction of this and there are good reasons for it.

• Deeply embrace URI addressability.
• Use Ajax as the face of your SOA.
• Monetize your SOA.
• Enable users as service consumers.
• Use virtualization, fast scaling, and on-demand architectures.
• Offer SOA services visually, through widgets.
• Consider JSON as a service option.
• Encourage and discover emergent solutions.
• Leverage the Global SOA.

Read Eleven Emerging Ideas for SOA Architects in 2007 and consider the consumption-centric viewpiont being espoused. Will these ideas from the consumer Web, which are frequently resulting in rapid uptake and consumption, work for us in our businesses? Message was edited by: joeo@enigmastation.com

Where these ideas generated with this tool by any chance? Sure sounds like it..

Where these ideas generated with this tool by any chance? Sure sounds like it..

The other way around: see Bullshit Bingo Thanks to my colleague Peter...

This is the kind of stuff decent developers have to suffer every day: managers mistaking marketing bullshit for The Only Thruth. Articles like this trigger fever dreams in decision makers that don't have a clue about how little a couple of neatly fitting boxes and lines on a presentation have in common with actual implementation. Chris

I must recommend that you segregate issues of presentation. Points 1, 3, 4 (maybe), and 8 blur the line between presentation and business logic. Let us not preoccupy ourselves with eye candy until we are sure that we can deliver correct semantics. In point 4 what I think you are saying--at any rate, what I think you should be saying--is that AJAX is not just about whizbang UIs but can also assist (not routinely, but in edge cases) in dividing responsibility between the presentation and business-logic tiers. If this is what you meant then it could probably be made a little more explicit.

I hate articles like this. First it mixes SOA with web services and secondly and even worse it attempts to mix presentation and business logic. Your internal services should be implemented using technologies appropriate to your needs. If you do use web services, then SOAP is probably what you need to use for inter- and intra-system communications because it has WS-* support to deal with the sorts of requirements inter- and intra-system services have. As far as supporting clients is concerned, services should be completely agnostic and unaware of clients. I agree that REST is generally better suited for client communications than SOAP, but that doesn't mean you change your services, it means you support what you need for browsers in the server-side presentation tier. If you're are doing document/literal SOAP, REST is a piece of cake. In any case this seems more of an issue for the presentation tier "architects" than the SOA "architects". Finally, what is a "SOA architect"? Is that an architect who knows SOA or an engineer who knows SOA type technologies (e.g. web services)? How is that different from a "J2EE architect" or a ".NET architect"? Can you be so narrowly focused and still be an architect?

+1

I hate articles like this. First it mixes SOA with web services and secondly and even worse it attempts to mix presentation and business logic.

+1

Can you be so narrowly focused and still be an architect?

First it mixes SOA with web services

Considered linguistically "Web Service" definitely looks like implementation of "Service Oriented Architecture" :) Speech shapes what we think

Considered linguistically "Web Service" definitely looks like implementation of "Service Oriented Architecture"

You can implement lots of services and lots of web services without doing SOA. SOA extends component-based architecture. It is data centric. It's service operations realize use cases. I can have tons of services and not do any of that. When you slap a service interface in front of legacy code you have SOI, not SOA - and that may be good enough for now in many situations. You just forego the benefits of component substitutability and reuse that give you flexibility adaptability and lower life cycle costs.

Finally, what is a "SOA architect"? Is that an architect who knows SOA or an engineer who knows SOA type technologies (e.g. web services)? How is that different from a "J2EE architect" or a ".NET architect"? Can you be so narrowly focused and still be an architect?

Excellent point. Enterprise architect should be the job title. Marrying yourself to a platform or a buzzword misses the point, though service-orientation does encapsulate a lot of principles enterprise architects will be following in the future. Also, good point noting the difference between service interfaces and SOA. Far too often you hear criticism of one applied to the other. Web services aren't terribly complicated. The world abounds with them. Obviously they can require some work (what doesn't?), but they are far from arcane. On the other side of the coin, SOA is not married to a handful of Web services specs. If anyone's interested in a spec-free example of how to wade into SOA, here's a case study from Dutch financial company ING Card.

How is that different from a "J2EE architect" or a ".NET architect"? Can you be so narrowly focused and still be an architect?

Excellent point. Enterprise architect should be the job title. Marrying yourself to a platform or a buzzword misses the point, though service-orientation does encapsulate a lot of principles enterprise architects will be following in the future.

Sorry, can't help myself from dragging an old quote out and modifying it a bit: "Sun Certified Enterprise Architect" is to Enterprise Architecture, what McDonalds is to fine cousine. Feel free to apply my quote to any technology-specific "Enterprise Architect" certification. And yes, I am personally closer to the J2EE architect than Enterprise Architect. Just don't be surprised if you are not invited to the interviewing round, when applying for a position as Enterprise Architect based on the above mentioned Sun certification :-)

Sorry, can't help myself from dragging an old quote out and modifying it a bit: "Sun Certified Enterprise Architect" is to Enterprise Architecture, what McDonalds is to fine cousine. Feel free to apply my quote to any technology-specific "Enterprise Architect" certification. And yes, I am personally closer to the J2EE architect than Enterprise Architect. Just don't be surprised if you are not invited to the interviewing round, when applying for a position as Enterprise Architect based on the above mentioned Sun certification :-)

Absolutely true, but that gets back to having yourself tied yourself to a platform. Sun, J2EE, both are tangents off the architecture curve. I'm not knocking those skills, I'm just saying that it's more about Sun or J2EE in those cases than architecture. If you're an insurance company or a retailer or a hotel chain what you're interested in people who can design an IT installation that best serves the needs of your business. How do you get the most bang for you buck for you IT investment? How does your application base work as a whole? That's where the enterprise architect's focus ought to reside. Being a Sun-certified probably qualifies you to work as a consultant for Sun or inside a big Sun installation. It would be nice if there were a standard certificate or degree that conveyed expertise in designing an application infrastructure for maximum utility, but there isn't. Doesn't stop companies from searching high and low for people who can do it though. It's probably the folks who've started doing it where they already are who'll be getting the interview invites in the future. Experience likely will be the trump card for the forseeable future.

It would be nice if there were a standard certificate or degree that conveyed expertise in designing an application infrastructure for maximum utility, but there isn't.

Well, the subject matter in this area is a lot less "tangible" than the product-specific architecture. If I were to make any sort of recommendation, based on what I've met out "in the wild", I'd point at TOGAF perhaps supported by some knowledge of ITIL and Prince2. You may also run into Zachmann and a multitude of other EA frameworks and methods. Also, don't neglect the non-technology focused areas, such as organizational design and change. Having experienced a lot of different organizations as a consultant, I can tell you that even the best of IT solutions and skills, can fail if not supported by a proper organization.

... in my view. In my opinion, our business is still so new that learning by experience is vital. So, while I agree that a 'J2EE Architect' or a '.NET Architect' is not the same thing as an 'enterprise architect', I would like to see significant work in several technology-specific areas from a candidate. I would argue that nobody knows how to design an application infrastructure for maximum utility at this point.

... in my view. In my opinion, our business is still so new that learning by experience is vital. So, while I agree that a 'J2EE Architect' or a '.NET Architect' is not the same thing as an 'enterprise architect', I would like to see significant work in several technology-specific areas from a candidate. I would argue that nobody knows how to design an application infrastructure for maximum utility at this point.

True, but an architect does not confine him/herself to one platform or technology. In a related vein, I don't believe you really know how to program if you have not been proficient (at some point) in more than one programming language. It's difficult if not impossible to abstract out the essence of the task (architecture, programming, etc.) until you can separate the implementation from the idea. Being (or having been) proficient in multiple implementations (platforms, languages, etc.) gives an opportunity to gain the requisite perspective. Architecture does not happen down in the weeds - that is engineering. A good architect is most effective when teamed with a solid senior engineer.

Hi Dion,

I think Service Oriented Architecture (SOA) wouldn’t be anything without some of the techniques constantly available from the internet.  IMB have a signature in this regard. However, which of the 3 aspects or certification is the most preferred from SOA point of view? Personally, SOACP has been my preference. There’s a lot of talk these days on “PMP SOA Project Manager”. The combination seems very beneficial but what of course there has to be some blemish somewhere. I leave that to the experts. 

 

Sarah Mogan

firebrand Training

PMP certification