Hiring SOA Consultants...

Momentum is opening up new positions for SOA consultants. All positions are travel intensive and require a strong background in distributed computing and enterprise architecture. Interested candidates should send Melissa a note: careers@momentumsi.com

We're basing the consultants in one of three delivery centers:
- Austin / Dallas, Texas
- Reston / Washington D.C.
- San Francisco / Silicon Valley
------------------------------------------------------

The Service Architect
At Momentum, the Service Architect is responsible for analyzing architectural requirements and translating into service based solutions. The architect will work with various existing architectural styles (monolithic, client/server, 3-tiered) and modify those systems to accommodate a service based approach. The architect will also be responsible for identifying SOA based solutions to the non-functional requirements (security, transactional integrity, reliability, availability, agility, etc.) Lastly, the Service architect will be instrumental in creating Software Architecture Documents, identifying components, estimating time-to-transition, providing guidance to designers and developers and linking architectural investments back to financial returns.


Requirements:

The SOA Architect must be well versed in Enterprise Architecture, Service Oriented Architecture (SOA), J2EE and or .NET Architecture.
Full life-cycle implementation experience (requirements, design, implementation, integration, testing).
Experience designing and implementing n-tiered application architectures.
Fluency in first generation web services standards, technologies and tools (e.g., XML, SOAP, WSDL, UDDI, BPEL, etc.).
A strong distributed computing background is a requirement (CORBA, RPC, DCE, DCOM, RMI).
Familiarity with messaging systems is a plus (Tibco, WebMethods, MQ, SeeBeyond).
Familiarity with commercial Web service products is a plus (Systinet, Blue Titan, etc.).
Knowledgeable on WS-* standards.

Other:

• Strong interpersonal, strategic oriented thinking and excellent written and verbal skills are essential.
  
• Ability to present professionally and persuasively to C-level executives.
  
• A minimum of 10 years experience overall in software development.
  
• A degree in Computer Science is preferred.
  
• Travel is required for this position.
  

About MomentumSI
MomentumSI is a pioneer in service oriented architecture, integration, and application development. Since 1997, the company has built a reputation as a leader in architecting large scale distributed computing solutions for IT organizations. Today, MomentumSI is at the forefront of service oriented architecture and integration for enterprises. We built the first Web service orchestration server for .NET and have been an active member of Web services standards groups, such as OASIS. Momentum continues to invest our SOA practice and is looking for the best of the best to join us.

Entire Software Sector up on Web Services!

Now this is interesting:

NEW YORK (MarketWatch) -- Goldman Sachs raised its rating on the software sector to attractive from neutral on the belief that the emergence of Web services architecture will accelerate industry growth and on expectations that share prices will rise as investors position for an anticipated year-end rally. Analyst Rick Sherlund believes a movement to a new generation of Web services base standards, which will result in more flexible and adaptable systems that can allow for changes in business processes, could reinvigorate growth for information technology vendors. He said the Phase I adoption of infrastructure software from IBM , BEA Systems , Oracle and Microsoft to enable the new standards is well underway, and the Phase II re-architecting of existing applications from SAP , Siebel and others is upcoming. He said Phase III will be integrating the new standard into desktop systems, which should stimulate a replacement cycle. Sherlund recommends positioning in the expected leaders of the next generation systems, even if the benefits aren't expected for a few years, given attractive valuation and the anticipation of a typical year-end rally.

See: http://biz.yahoo.com/cbsmb/050523/390440d059074e4881ce4b5a86c54332.html?.v=1

Increasing Reach

Software reuse has always had issues. In my opinion, the most common types of reuse are:
1. "Copy & Paste Reuse".
2. Off-The-Shelf Reuse - Here, we leverage JVM's, .Net API's, J2EE libraries, open source offerings, etc. that are pre-built and providing immediate value.

The third (and elusive) category would be the homegrown libraries - often domain specific. Let's be clear - the more general the problem, the easier to reuse; conversely, the more specific the problem, the harder to reuse. The easy stuff is packaged in your favorite off-the-shelf library - leaving the more difficult stuff for the I.T. department.

Reuse is difficult - and reuse via language specific code snippets is often easy but fails to scale and provide real value. Reuse via off-the-shelf packages is great - but in many organizations - this one has already been tapped. This brings us to Reuse Through Reference.

Services are a great mechanism for providing reuse through reference - however, many people seem to forget one simple item: REACH.

Reach describes the 'reusability potential'. Imagine having 10 systems 9 of which were in COBOL mainframe apps and the 10th was a .Net application. Let's state that the COBOL applications don't have the ability to access the native services provided by the .Net application, but do have the ability to talk Web services. Interesting - I just stated that it can speak "Web services" - does that mean WS-I basic profile? Which other WS specs does that include?

In an attempt to increase reuse through reference, we (the enterprise architects) are finding the need to increase reach. This means that we must identify protocol ubiquity levels within our organizations and quickly create critical mass.

Generally speaking there are two methods for increasing the reach:
1. Modify the connector capabilities at the endpoints (COBOL apps, etc.) via service enablement (WS-PaintJob)
2. Provide protocol mediation/translation in the network.

WS-PaintJobs are an easy way to black box systems and increase reach. However, the total number of protocol permutations between any given client and any given service grows exponentially with the size of the service network. This leads to the realization that a protocol mediation strategy is not only useful but mandatory.

The Client-to-Service Ratio

It is natural for people to think about their SOA in terms of the number of services that they have created. And as one person joked the other day, every company seem to report having between 200 and 500 services. The criteria for being a service tends to vary significantly - anything from XML over JMS to EJB's to WS-I compliant Web services.

Service Architects love to brag about the number of services - and I let them. Actually, I encourage them to brag. However, I'm quick to challenge these same people with a very simple question:

"200 SERVICES! That's great - but how many clients???"

This simple question usually makes the most pompous architect fall to their knees in shame.

You see, one of the reasons that guys like me go around shouting "SOA, SOA, SOA!" is because we believe that a sharable infrastructure can be used across "applications" to enable a new level of productivity. Yes, we believe in the unicorn called "reuse". The "how many client" question hits at the heart of the share/leverage/reuse debate. I know it - they know it.

Back to my story - I ask the question, "How many clients" - and I stare at their face like a CIA agent looking for twitches. Within seconds, I witness the five phases of panic :-)

Phase 1: "Oh crap. I should know this."
Phase 2: "I better make up a number - I told him 200 services - hence I'll tell him 200 clients!"
Phase 3: "Nope - that won't work - he'd realize that my client-to-service ratio would be 1:1 indicating that I wasn't getting any leverage."
Phase 4: "2:1 seems high at this stage; 1.5:1 seems believable... yea, (1.5 * 200)=300... but I can't tell him 300..."
Phase 5: The Service architect looks me squarely in the eye, head shifted slightly to the left and says "Currently, we have 322 clients."

And I say - "Excellent" followed by a slight grin and a playful stare indicating that I was 100% aware of what had just occurred. I usually then move to relieve the 5 seconds of torture and lies that I just put them through by saying something like, "Well - it is still early; SOA is still evolving and you won't see that number climb until more of the organization adopts it." And my friend gladly take the bait - "Absolutely! Right now, we're just building out the core services - we're confident that the ratio will increase over time."

And I move on to question number 2...

Nokia & Web Services

VNUNet.com reports:

"Nokia has vowed to build support for web services into all its smartphones by the end of the year.

The firm explained that the development push will include support for common software standards including Soap and XML, as well as for more intricate applications.

In the future both the Series 60 smartphone operating system and the Series 80 software used in the Communicator range will offer full web services support.

"By 2006 all Nokia smartphones will be web services enabled," said Timo Skytta, director of web services at Nokia.

Most excellent!

SOA - PHASE III

Several of my buds have been giving me a hard time. They're claiming that I've checked out of the SOA world. And as an emerging tech. guy, I'll agree.

You see, from my vantage point - SOA & Web Services have already crossed the 'value' threshold and are ready for adoption (Gartner is wrong.) Dare I say that WS is no longing 'emerging'. We have now entered phase III.

Phase I was basically 'protocol oriented' - with a focus on the WS-I Basic Profile (SOAP, WSDL, UDDI, XML Schema). Phase II was the WS-* stack (the aspect oriented protocols).

Phase III is about the using the darn things. Whacky, eh? You see, I talk with hundreds of companies about their utilization of web services. In most cases they tell me this:
1. We connect fat .Net clients to Java application servers (and use soap in between)
2. We connect to some ASP (like Amazon, SF.com, etc.)
3. We front ended some legacy system with services.
The same companies will brag about their rich utilization of UDDI, Fabric, ESB, etc.

However, when I ask about SOA from a reference architecture perspective, I mostly get blank stares. Then, I go to the white board, hand them the marker and say, "draw your architecture and show me where you use services." And in almost every occassion they draw an application architecture which is usually a 3+N (the usual 3 tiers plus roughly N external services - pick your favorite - LDAP, EII, orchestration, etc.)

So after seeing the same thing at several different companies you begin to realize that the world is landing on patterns of usage (and yes, 3+N is the most common). But rather than calling these 'service patterns' or something like that, they are really just architectural patterns (that use services).

Full Circle.
It's true - I'm less interested in watching protocol geeks fight in OASIS about non-sensical issues. We're finally here. We're finally at a point where we can use this stuff to create business value. That said - phase III is all about facilitating the adoption. And yes - expect to see pre-canned architectures that use SOA. But beware - the shift is heading back to 'architecture as a whole' and reviewing the place for SOA / WS in our upgraded world. You see SOA Phase III is really about putting cleaning up our distributed architectures and applying SOA appropriately.

Architecture Change Request (ACR)

There are a number of studies that discuss the impact of failing to adequately express system specifications. Oddly, most of the studies focus on the 'functional' side of the equation emphasizing the Use Cases or similar requirements document. As more and more of our work efforts are being moved to assembly line creation (outsourcing, off-shoring, remote development), it is becoming much more important to clearly articulate system specifications and the change requests.

I've witnessed teams go through great pains to version control the least important documents in the system. Source code, JavaDocs or test cases will be meticulously controlled, while the over-arching architectural documents will often go unattended. When they are versioned, they are usually treated as a BLOB, with no ability to perform a "Diff" or to maintain an automated digital log of the changes.

As organizations begin to adopt digital described reference architectures and use those elements to digitally describe their candidate architectures, they will find the ability to perform the 'diffs' and to manage change at an acceptable level.

Suddenly, we begin to see our architectural process looking much more like traditional hard-goods engineering process:


The Architectural Change Request (ACR) enables a software development team to track the changes to one of the most important elements in the SDLC, the architecture. Keep in mind, when architectural changes are made the impact (time / money), is usually significant. I firmly believe that the ACR/ACO process will encourage application architects to think and plan their architecture out more thoroughly at the initial stages leading to less rework after the project is initiated.

ADL, IDL & EDL

There are several different ways to review elements in an architecture.

1. You can look at the "interfaces" to identify the entry and exit points. Obviously, this is a big part of what web services are all about with WSDL as an "Interface Definition Language" or IDL.

2. You can look at the "engine" that provides the base infrastructure: "It's a database! It's a Rules Engine!", etc. Or more precisely, "It's an Oracle Version X database, with clustering". This is the "Architecture Definition Language" or ADL.

3. In addition, you can look at the mechanism that is used to "extend" the "engine" which provides the "interfaces". In an orchestration engine, the extension language might be "BPEL", in a presentation engine, the extension language might be "JSP". Once an EDL is identified, you can begin to look at the capabilities of the extension mechanisms (language features, libraries, etc.). Unfortunately the industry remains very immature in this area. However, I am confident that as the industry begins to understand the basics of a "language to create/describe languages" the art will quickly advance.

The software community is making progress in describing the systems we build. Our meta-descriptions of our building blocks and finished systems is a huge advancement toward the vision of the "software factory", "software IC", or which ever metaphor you prefer.


-------------------------------------------
INSIDE, OUTSIDE, UNDERNEATH & ALL TOGETHER!

Web services & SOA make people think about architecture from the "OUTSIDE" - that is, the external interfaces. The "EDL" allows you to evaluate it from the "INSIDE" - or how you build that which is exposed. The ADL facilitates "UNDERNEATH & ALL TOGETHER".

Although one of the primary benefits of SOA is to abstract the consumer from the architectural elements and extension mechanisms, this doesn’t mean that the architect that is creating the solution can avoid the issue. I firmly believe that the opposite is true. SOA architects must apply equal attention to these concerns as they do to their uniform interfaces, mediation strategies or WS-catalog taxonomy.

----
Note: I'm using the term EDL to describe the capabilities of a DSL or a general purpose programming language.