Got Money, Will Buy Sophistication

Globalization has brought many disruptive changes. The Internet and ease of communication have made it easy for companies to stretch far beyond their traditional boundaries. As a result, companies are opting for inorganic growth by M&A –- not just in their neighborhood, but all over the world. M&A is commonplace in in developed economies. American, European, and Japanese companies have been doing this for years. Brands such as Coca Cola and Honda are virtually in every town on the face of the globe. Now, however, the developing economies are also jumping in the fray.

Rapid growth (say in the 8-15% range) in the developing economies means that they are growing fast and furiously but it also means they are flush with money. On the flip side, most of the developed economies are experiencing tepid growth (1-3%), if any, and are battling with wide-scale problems such as subprime mortgage crisis, unemployment, high gas prices.

On a side note, I recently read that fuel costs have doubled for the airlines in the last year. And given the amount I pay at the pump, I think the family will be taking a not an airplane vacation, not a road trip, but a hike this summer!

The growth patterns between developing and developed economies makes for a perfect breeding ground for M&A in the reverse direction; that is, companies in developing economies are buying troubled brands in developed economies. This is a best way to put their money back to work and fuel inorganic growth.

All that is well and good; makes sense from a company strategy point of view – expand. Makes sense from a financial point of view – invest for the future. I don’t think anyone stopped to think of what else these developing country- companies were buying … their treasure chests filled with cash were buying one more thing that they may not have expected – Sophistication. As with any M&A, each time companies expand and gobble up companies elsewhere they have to merge the people, processes, and of course the IT landscapes. In any acquisition, the acquirer usually has an upper hand on determining which of the people, processes, and IT artifacts would survive. Historically, the acquirer, presumably, is better at all of these hence the better financial & growth prospects affording it M&A opportunities. However, right now we’re noticing something different. The developing country companies are the ones that are successful and cash rich – they are part of a nouveau rich class. They’ve filled their coffers rather quickly and all the while not paying much attention to sophistication of internal procedures, processes, and environments. As one IT director of an Indian-client commented, “Embarrassing for us, we bought companies that are more sophisticated in terms of processes than the acquirer.”

So the client asks us about how to marry the uber-sophistique with it-just-about-does-the-job-so-it-will-do? This situation is perfect example where the loosely coupled value-prop of SOA fits well. You don’t need to blindly copy the sophistication (and potentially make a fool of yourself while spending big bucks on system replacements). Just agree on the interfaces (service contracts) and then handle the ease (or complexity) within each of the two environments to bring info up to that interface point. So long as the service contract is abided by, the co. keeps humming and the marriage stays out of trouble!

I Can Give It Away Only If I Can Get It Back My Way !

If the past two recessions (mid nineties, early 2000) taught us anything it was this: the tech sector is disproportionately affected by economy slowdowns. A colleague of mine in sales for a large network equipment provider claims he can “smell” a slowdown months in advance. His trick is watching the purchase orders. All of sudden projects and purchase orders have a 3 months or less window. Managers with signing authority start to sign for things needed this week, maybe next month; but plans further out get shelved.

However, a relatively small sub sector of the technology market seems to have found recession armor – its business model provides it with what seems to be a recession defense mechanism. Companies in this sub sector offer their services as internet-based business processes or what is known as “Software as a Service” (SaaS). Getting started with SaaS is relatively painless because the deployment procedures, hardware procurement, software installation, maintenance schedules are all taken care of by the SaaS vendor. It also can be much less expensive than custom applications or even in-house deployed 3^rd party software. However, very quickly into the cycle the customer realizes giving it all away (valuable enterprise information along with management of the software) is only feasible if it can get it all back. As soon as it goes out, the information created and stored in these 3^rd party Software Services needs to flow right back to the customer and vice versa. Sounds like yet another integration but it’s not when you consider various types of information manipulation required to get data in the appropriate form as well as myriad systemic idiosyncrasies of each application and SaaS vendor involved in such information exchange.

At one of our clients, we moved to Salesforce.com – a SaaS vendor for sales information storage (things like price, purchase history, etc). A few questions arose immediately. Sure it’s less headache if the Salesforce.com manages sales related data. But what about the in-house ERP system needing it for order management purpose? How many other in-house or SaaS systems will need it later? What platform, formats, and protocols, should we support/address with perceived information exchange needs in future? And which of these systems is source of truth for a data element at a certain point in the lifecycle? While some such questions have generic answers, a significant chunk needs tailored solutions. SaaS vendors have way too many customers to create or support custom integrations for each one. The integration needs generated from “giving it all away” are too enormous for any SaaS vendor to take on. Oddly (or mystically) enough, just around the time that SaaS vendors started to take shape an answer to this problem also was brewing. Yup. If you are thinking, “this is an SOA Musings blog so the answer must be SOA”, you win our critical reading comprehension test!

Service Oriented Architectures and the standards that come with that provide self-service integration for customers of SaaS vendors. As long as the vendor provides standards-based interfaces, I can take those interfaces and publish data to the vendor or retrieve data out and massage it to any format I need. We recently did just this for the aforementioned client. This doesn’t mean there are no catches and gotchyas. There are plenty along the integration brick road but at least the heavy lifting is done and for the most part you are left with some XML manipulation, configurations, and business process development.

It’s no wonder SaaS vendors seem to be the stalwart of the technology sector. Look at the checklist for an IT manager:

* Easy to Install: installation handled by SaaS vendor
* Easy to Manage: management handled by SaaS vendor
* Easy to Upgrade: Upgrades handled by SaaS vendor
* Easy to Ingrate: Standards-based integration can be done using SOA technology (however, in
general, no custom programming code to manage and maintain)
* Easy to Secure: YES (def. compared to 5-10 years back)
* Relatively Inexpensive: Yes

I saw how relatively painless it was to integrate with salesforce.com. Looking back over my 15 years in the industry, I can def. say that SOA has brought 3^rd party integrations to a new level of ease and comfort. SaaS vendors would never have been the strong horses they are now before SOA. It was a really big deal to move company information outside the stone and iron gates of corporate America’s data centers. Hours of paperwork, approval-gatheirng and network changes needed to be made. Things like firewall holes needed to be created. And imagine trying to change vendors or cancel the partnership all together? The same pain all over again and worse if you want to get your data back out. Compared to that, the work we did when we architected the Salesforce.com integration was def. painless and to me SaaS and their integrations are not just a fad—they are the way of the future.

Once Bitten, Twice Shy

Once Bitten Twice Shy

At a client of ours, Web services were all the rage a few years back – maybe 4-6 years ago. Hearing about all the noise of the new paradigm, the IT dept there decided to embark on a Web services project as well. Busy minds worked head down researching the capabilities and the use cases that were associated with this and finally a proposal was put forth.

The proposal was essentially to offer various IT functionalities as Web services and then for IT applications to dynamically discover and bind to the most appropriate fit. Sounds vague and shocking? It was just as vague and shocking back then and the business teams at the client were just as skeptical. The project took two steps forward, five steps back; until finally it was laid to rest and Web services were forever labeled nothing more than "Hype".

Fast forward to 2007 and now we come in and propose SOA as the A2A and B2B integration substrate. And the feeling of being "once bitten – twice shy" was quite overwhelming. The reaction from both IT and business was exactly the same. “SOA!?! You mean Web services? Oh no, we tried that. It didn't work for us. It’s not for our type of business." And there began my efforts to explain the difference between Web services, the technology, and SOA, the uber-integration architecture. At the crux of my arguments was the idea that SOA is about integration rather than dynamic discovery. It's about loose coupling of integrated applications. It's not about dynamically choosing your business partners at run time. It took quite a few discussions for me to give SOA the confidence as the paradigm of choice. Our client was definitely skeptical but as of today they have a purchase order signed, sealed, and delivered for a SOA platform from one of the big guys and I sit with my soda and pizza and several architecture documents detailing the new SOA to be implemented over the next few weeks.

How many hammer strokes does it take to shape a rock?

We are all aware that any IT project is full of challenges. The ones that involve changing strategy are even tougher. But those related to SOA adoption are perhaps in a class of their own.

Enterprise architects in a company find it difficult to get the IT community rallied around SOA Strategy and Adoption programs. An EA manager recently lamented that as far as SOA is concerned, he would need to start looking at the calendar and "throw that watch away!" Sadly, he is not alone. Many strategist-practitioners have expressed dismay over how long it takes to move even an inch with SOA projects. One always wonders “Can’t we do it faster? Why can’t we just bring all people and all apps to SOA Wonderland in one go?”

The problem lies not quite with people resisting change, but more with people’s understanding of SOA. Some people simply want to put a SOAP façade in front of every application. These people consider SOA adoption as tactical issue not fitting in the strategy domain -– “Just create a timeline to add SOAP interfaces to all applications in the company”. Others ridicule the idea of finding a service on-the-fly and simply start using it -- “Companies would never do business like that!!!” Yes, those are things you hear when you ask about SOA, but that’s not exactly it. It’s not that straightforward or ridiculous. And this is not the complete list of misconceptions people have regarding SOA (another one: “I don’t want others to use my Web service until I can charge their location code).

In comes an SOA Strategist whose primary job is to do away with such misconceptions and apprehensions. Yes, SOAP interfaces, service discovery, reuse will all be involved in SOA adoption. However, a workable SOA adoption strategy involves creating (or adopting) a place for all of these, a context in which they are applicable and a process to do so. And this takes time. It involves qualifying service-worthy resources, creating service registration and governance processes, and a resource sharing and cost sharing agreements. Of course, not all such aspects are applicable in every SOA strategy. Nonetheless, these measures will ensure that the SOA adoption goals are not marginalized and people understand what it is and what it takes to make it happen. Taken together, each such step is building a robust SOA for the company.

Recently, while working with a client on SOA adoption, I discovered an excellent analogy for that. I’ve been working with an enterprise architecture group in a company that is putting forth a roadmap for IT to adopt SOA. Despite several slides, documents, POCs and use cases, there seemed little movement in an SOA direction. But just when everybody thought we should give up, a series of Aha’s led to the first ever SOA-based project to be implemented for the company. The IT director with the group shared a childhood story; one day he was watching his grandfather, a mason, shaping a rock by moving a big chunk off it. After that was removed, the grandfather asked, “So which stroke shook away the stone piece?”. “The last one of course” answered the young grandson. “Nope”, replied the grandfather “Every single stroke did it – a little every time.” What are your experiences with implementing SOA strategies? Is the mason right?

Are boutique Sis better at introducing new technology platforms?

I've worked for large companies, small companies, start-ups and I've worked with various technologies – in all phases of their maturity life cycle everything from mainframes to ERPs, to client-server to SOAs. Over the past 15 years in IT something that has always proven to be true by observation, if not by science is that boutique SIs are uniquely suited to introduce a new technology platform.

I look to HP (later on an Agilent division) as one example. Back in 90s when corporations were testing the waters with ERPs, it wasn't the big 6 firms that came to the rescue. It was the smaller, local boutique SIs that came in to help lay the foundation for small scale ERP projects. Of course by the mid-to-late 1990s, all the big consulting firms had their ERP practices (much of which was acquisition of the aforementioned small boutique firms or their employees).

Fast forward to today and we again see the same cycle with SOA. Small boutiques SIs are slowly bringing SOA technology to the table for large corporations. Without naming a certain valley software company, I'll share this-- a pre-sales guy I recently worked with even told me that he prefers to work with boutique SIs rather than the consulting arm of his own employer. So what is it?

I think it comes down to a few simple ingredients that the big companies can't replicate for each and every new technology because the risks are too high for them. What boutique SI offer is the following:

• Intense expertise in the new field
• either having invented part of it, worked on it from inception, or simply having earned the stripes through a few major projects
• Flexibility to work & invest outside a set project plan and strategies
• Lessened (yet loftier) expectations
• Boutique SIs often afford the luxury of having lessened expectations from a project management perspective. Large companies are expected to look, act, and behave a certain way; often tying their hands. Boutiques can shuffle around people from client to client and while there might be downtime here and there, clients tend to forgive and adjust more than with a Fortune 500.
• Don't let the lessened expectations lull you into a sopophoric state. Boutique SIs are not strong on the cash flow statement, they involve more risk, tend to be over all younger. There is an expectation from the client that the risk is made up for with a unique, cost-effective, and elegant architectural use of the new technology. The end goals are definitely loftier on the boutique SI.
• Boutique SIs are as famous as their last success; whereas larger consulting companies, independent or arms of software companies are assured some level of business because of their name and history. Customers benefit from the hunger to succeed that Boutique SIs are motivated by because they will find ways to make things work with available resources (people, h/w, technology, time, otherwise).

At a client we recently worked at, two of the valley's big guys did not deliver. Overall, the client was left feeling frustrated. We were brought in to guide the architecture and development of the SOA; however, the overarching project was handled by the big guys. Needless to say, we have been asked to own a larger piece of the puzzle for the second phase; we can and will make things work whereas the big guys proved that its more important to have all the i`s dotted and t's crossed.

Network is the platform is the os is the app is the database is the...

As I sit there sipping my coffee in Mascone auditorium, I can't help wondering what John Chambers is doing at Oracle conference. Sure they both use each others' technology and probably sell loads of each other's gear, but a keynote? I'm dying to know which stars are aligned what way to make that happen.

The lights begin to flash wildly and the music starts to blare ending the crescendo with big bold Oracle logo right at the center and everywhere else. John appers, declares his allegiance to Oracle
partnership and jumps right into "making you uncomfortable about the future." He is making his point well about convergence of devices, hyper-personalization (my coinage for individuality of connectivity and content to max); but I'm still scratching my head -- Other execs from likes of Motorola are happy to give a sound bite in a 30 second video touting Oracle technology, but what makes John drive up all the way to SF from San Jose?

Halfway through the presentation, a pattern begins to emerge. Even though traditionally, Cisco has been a layer 2 to 4 (of OSI model) vendor, now things start to look more attractive on layer 7
(Application) level. During the demo, Cisco phones are sporting ball park e-tickets and discount coupons, Cisco video conferencing is helping solve crime on new TV series Vanished. The ubiquitous IP network (Cisco's traditonal playground) is of course making that happen, but it is taking the back seat in John's messaging. Hmmm... it's no longer just about the network.

On a slide animation, technical buzzwords rapidly begin fall off from application and OS layers down to the IP layer. Network is the next platform -- John declares and Cisco will take the leadership in making it happen (of
course). Essentially, what John was proclaiming that now Cisco also wants to be a serious player in application layer space. That should heat up the competition and thus it would be good for technology consumers. So what would it take for Cisco to make it happen. Throughout the glitzy presentation, John is alluding to benefits, we don't yet see the moving parts under the hood. And then I see it. On the slide showing top 5 priorities for Cisco, SOA makes its appearance! Now there is a big turning point for a technology.

We started with the application vendors like Microsoft, IBM, and Ariba evangelizing the technology, middleware vendors like Oracle and Tibco picking it up, through in-house development or acquisition or both, and now networking vendors are making it as part of their mainstream strategy.

Future should be good for SOA professionals. Viva SOA!

Ugly Ducking

In the past few days, we had somewhat painful discussion with one of our clients. This client is embarking on an SOA based project that I'm quite excited about. Of course as in any other project, almost right after launch, we realized that we have bandwidth shortage problem. Rarely does a project exist where the scope is lighter then the resources and the skill sets involved.

Being the SOA strategist for the company and de facto architect of the very first SOA implementation, the ball fell in my court to find someone that fit the bill. "That should be easy." I mused. I just need to bring in some of the folks we work with if we are short on bandwidth in our company. Few phone calls and we have someone available! That in current state of the economy is an achievement! We talked about the whole arrangement and presented the person to the client. They all liked each other and everything was right on track -- until procurement got involved that is.

While talking to guys in the procurement maze, it became clear that they had a different view and take on the whole thing. The department had created a set of job profiles and related rate ranges. That sort of thing works well for most mainstream skill sets. It makes sure that the cost of certain skill set is streamlined across different departments. IT managers from all over the company can query procurement about what a typical, say, system administrator would cost. In this case, after the initial discussion, procurement folks concluded that this is a "software developer" requirement and thus falls within a certain rate range.

Now, I'm not going to judge how much they should pay to whom, but I can certainly say that SOA solution developers are not as plentiful as, say, Java or J2EE developers. While most of them would have done Java development in the past (and may still do as part of the SOA solution), it's not the same. Essentially, Java != SOA and C# != SOA and XML != SOA

To me, SOA solution development requires a different mindset. The way services are architected (message formats, granularity, composability etc.) is different from a Java application. Simply exchanging SOAP messages doesn't make a service. One needs to learn and internalize difference between SOA and glorified client-server application. And we all know, that more learned you are, the more price you can command -- And rightfully so. The more specialized a skill becomes, the more the demand per person there is and the laws of supply and demand say, higher the price.

Of course, not everybody has to agree with that argument. What's your take? Is SOA consultant the ugly (read pricey) duckling of the pack? feel free to add a comment or send email to naresh@tasmanAve.com.

Incidentally, our story has a happy ending. We have the consultant working on the project now.