In 135 days.
Seriously - the Web service and SOA era will begin in 135 days.
Delivering Business Services through modern practices and technologies. -- Cloud, DevOps and As-a-Service.
Saturday, June 25, 2005
176 I.T. Jobs Posted in USA
In the last 24 hours, 176 I.T. and software related jobs were posted on Monster.com...
I was curious how many were posted in India however it was difficult to tell. Even when limiting the search engine to only return jobs posted in the last 24 hours, the number posted exceeded the limit. I attempted to further tune the search criteria but was still hitting limits.
My best guess is that in the last 24 hours approximately 3,000 to 4,000 jobs were posted on Monster.com for India.
After sampling the job descriptions, it appears as though approximately 70% of the jobs posted in India were designated to fill U.S. demand. If this math is correct, that means that for every software job requirement that is posted in the United States, fourteen are posted in India to fill the same U.S. demand.
I was curious how many were posted in India however it was difficult to tell. Even when limiting the search engine to only return jobs posted in the last 24 hours, the number posted exceeded the limit. I attempted to further tune the search criteria but was still hitting limits.
My best guess is that in the last 24 hours approximately 3,000 to 4,000 jobs were posted on Monster.com for India.
After sampling the job descriptions, it appears as though approximately 70% of the jobs posted in India were designated to fill U.S. demand. If this math is correct, that means that for every software job requirement that is posted in the United States, fourteen are posted in India to fill the same U.S. demand.
Monday, June 20, 2005
AToM: Sun Needs to Learn From Microsoft
We have a clear winner in the quote of the month category:
Can someone please send me the name of the person at Sun who is responsible for this? (Yes, I'm still interested in seeing prediction #7 of 2004 come true... how sad.)
Anne Thomas Manes, a Boston-based analyst with Burton Group Inc., echoed those sentiments.
"What bothers me is that I really don't like JAX-WS," Manes said. "The Sun JAX-WS team really needs to learn a few things from Microsoft. They should be building something like Indigo—a common programming model that encompasses JAX-WS/JAXM, JMS, RMI and EJB. But Sun doesn't get that."
Can someone please send me the name of the person at Sun who is responsible for this? (Yes, I'm still interested in seeing prediction #7 of 2004 come true... how sad.)
Wednesday, June 15, 2005
The WSDL is the Offshore Contract
As more and more organizations move large portions of their I.T. department to offshore facilities they are questioning which activities to keep on-shore and which to push offshore.
For those that have chosen a service oriented path, the decision seems to be clear: "The WSDL is the Offshore Contract". In other words, domestic employees will work on business processes, enterprise architecture, orchestrations (agile controllers) and service design (up to the WSDL). And building the service? You got it - offshore.
It's an interesting line to draw, yet perhaps an obvious one. Using the "software contract" as the "legal contract" invites a clean division of labor and facilitates a simple approach for acceptance testing.
Obviously - the WSDL only defines the external interface leaving other aspects of the service (LIKE THE INTERNALS) to be described by other mechanisms. The algorithms and business logic are described with variations of the Use Case (think 'service case'). The relationship between the server and other elements (the hosting container, other services it calls, etc.) will likely be described by the System Definition Model, or some variation.
The science of describing architectures, interfaces and dependencies has significantly increased in recent years and it appears as though we are entering an era where the adoption level will skyrocket. The ability to describe systems in this fashion is what I've been calling 'precision specifications'. By using digital definition languages like SDM and WSDL, we are able to provide a 'software factory' with clear directions for construction.
Using 'services' as the unit of work appears to be a very manageable approach. Companies that are big into test-driven development will likely find test-driven-services a natural extension. Organizations that have adopted the Agile Manifesto may find this world too rigid. However, the Extreme Programmers may like the ability to lump X number of services into an iteration plan. And project managers will be thrilled to see acceptance tests directly linked back to line items on the Gantt chart.
I.T. organizations must increase their capability to describe systems with precision specifications prior to initiating a 'SOA factory'.
For those that have chosen a service oriented path, the decision seems to be clear: "The WSDL is the Offshore Contract". In other words, domestic employees will work on business processes, enterprise architecture, orchestrations (agile controllers) and service design (up to the WSDL). And building the service? You got it - offshore.
It's an interesting line to draw, yet perhaps an obvious one. Using the "software contract" as the "legal contract" invites a clean division of labor and facilitates a simple approach for acceptance testing.
Obviously - the WSDL only defines the external interface leaving other aspects of the service (LIKE THE INTERNALS) to be described by other mechanisms. The algorithms and business logic are described with variations of the Use Case (think 'service case'). The relationship between the server and other elements (the hosting container, other services it calls, etc.) will likely be described by the System Definition Model, or some variation.
The science of describing architectures, interfaces and dependencies has significantly increased in recent years and it appears as though we are entering an era where the adoption level will skyrocket. The ability to describe systems in this fashion is what I've been calling 'precision specifications'. By using digital definition languages like SDM and WSDL, we are able to provide a 'software factory' with clear directions for construction.
Using 'services' as the unit of work appears to be a very manageable approach. Companies that are big into test-driven development will likely find test-driven-services a natural extension. Organizations that have adopted the Agile Manifesto may find this world too rigid. However, the Extreme Programmers may like the ability to lump X number of services into an iteration plan. And project managers will be thrilled to see acceptance tests directly linked back to line items on the Gantt chart.
I.T. organizations must increase their capability to describe systems with precision specifications prior to initiating a 'SOA factory'.
Sunday, June 12, 2005
CIO's Aren't Taking SOA Serious
I'm going to make a quick prediction:
More CIO's will lose their job over SOA implementations than lost their job over ERP implementations.
I was chatting with a CIO the other day and asked him, "In retrospect, do you think you were involved enough in the early stages of your ERP implementation?"
He answered, "In retrospect - no - I wasn't involved enough. Had I known the size of it I would have definitely gotten more involved."
I followed up with, "Are you aware that an enterprise SOA roll-out will be significantly larger than your ERP implementation?"
He started laughing; he thought I was joking. My face didn't change. He quit laughing. "Jeff, are you serious?"
"Yes, I'm very serious. SOA is a complete overhaul impacting how systems are analyzed, designed, built, integrated and managed. And not just some systems - all systems including packaged applications like ERP."
He responded, "But with ERP, it was an all-or-nothing approach. Doesn't SOA offer an incremental approach - one that can be managed better?"
"Yes and No", I responded - "SOA is first and foremost about a network of services. The value of your service network is directly related to the effort of creating/obtaining services and making them available. All networks require a critical mass of 'valuable services' before they become useful to the consumers. The SOA service network is no exception. What I'm saying is that you can take a slow and steady approach to SOA but be prepared to receive gains that are even slower. Remember - this is really about the 'network effect'.
SOA done properly is a massive undertaking. It requires a rethinking of your infrastructure, development methodology, business impact analysis, budgeting process, organizational design... Don't underestimate the value it provides, the competitive advantage one can assume AND the investment it will take!"
It was clear that I had surprised my friend - perhaps even scared him a bit. And I realized that so many of the people in this space (vendors, analysts, press) are doing a disservice to the CIO by failing to tell the whole story: An Enterprise SOA implementation will be larger than ERP, Y2K and the Web.
Now is the time to get involved.
More CIO's will lose their job over SOA implementations than lost their job over ERP implementations.
I was chatting with a CIO the other day and asked him, "In retrospect, do you think you were involved enough in the early stages of your ERP implementation?"
He answered, "In retrospect - no - I wasn't involved enough. Had I known the size of it I would have definitely gotten more involved."
I followed up with, "Are you aware that an enterprise SOA roll-out will be significantly larger than your ERP implementation?"
He started laughing; he thought I was joking. My face didn't change. He quit laughing. "Jeff, are you serious?"
"Yes, I'm very serious. SOA is a complete overhaul impacting how systems are analyzed, designed, built, integrated and managed. And not just some systems - all systems including packaged applications like ERP."
He responded, "But with ERP, it was an all-or-nothing approach. Doesn't SOA offer an incremental approach - one that can be managed better?"
"Yes and No", I responded - "SOA is first and foremost about a network of services. The value of your service network is directly related to the effort of creating/obtaining services and making them available. All networks require a critical mass of 'valuable services' before they become useful to the consumers. The SOA service network is no exception. What I'm saying is that you can take a slow and steady approach to SOA but be prepared to receive gains that are even slower. Remember - this is really about the 'network effect'.
SOA done properly is a massive undertaking. It requires a rethinking of your infrastructure, development methodology, business impact analysis, budgeting process, organizational design... Don't underestimate the value it provides, the competitive advantage one can assume AND the investment it will take!"
It was clear that I had surprised my friend - perhaps even scared him a bit. And I realized that so many of the people in this space (vendors, analysts, press) are doing a disservice to the CIO by failing to tell the whole story: An Enterprise SOA implementation will be larger than ERP, Y2K and the Web.
Now is the time to get involved.
Sunday, June 05, 2005
SOA Training!
For the last couple years we've been training people in SOA and Web service technologies. Recently, we've added a couple courses including "SOA for Architects" and "SOA for Managers" - both excellent.
See:
http://www.momentumsi.com/services/training.html
I'd love to do a course on buidling your SOA Reference Model...
See:
http://www.momentumsi.com/services/training.html
I'd love to do a course on buidling your SOA Reference Model...
Subscribe to:
Posts (Atom)