Build vs. Buy...Part Deux

Often, decisions around how to solve a given business problem are simplistically boiled down to “Build versus Buy.” What is often lost in the shuffle is the fact that a business truly can get the best of both worlds in this regard, especially when using enabling software suites.

Larger and more complex organizations are often driven to the “build” decision because no packaged software exactly meets their needs. This can be an appropriate position to take, and even more so when the organization is dealing with rapidly changing business drivers, offering diverse business services, and needing to bring on large numbers of external customers which is often far too expensive from a licensing standpoint with most packaged software. However, when a considerable amount of the functionality needed can be provided by and/or exposed through a foundational enabling technology, businesses need to consider seriously the value of building that aspect of their technology infrastructure as opposed to looking at a packaged, supported, and actively updated solution. The question the organization needs to ask itself really boils down to “Do we want to be a software development company?”

In effect, when a business organization is presented with a solution from their technology team which appears to be a proposal to build an entire infrastructure and not a proposal to start solving their business needs immediately, they need to be concerned about the total time to solution and the hidden costs associated with the foundation-building efforts. Or even worse, they need to question if the foundation might be missed, yet again, and if they will therefore simply receive project by project solutions that leave them in the exact same position in which they started.

Agile vs. Waterfall

Borrowing from the Mac vs. PC ads, here's a cute video of two kids showing some of the differences between development methodologies.

Wow...it takes how many people?!

OK, so while I don't usually like to criticize other folks' approach to all this SOA stuff, I just read something over at soainstitute.org that just absolutely blew my mind.

The point of that article is purportedly to get across the appropriate staffing mix to have a successful initial SOA implementation. There are no fewer than 10 separate types of people described therein ranging from architects to security specialists to "archivists" to governance specialists and more. Even if you figure that on a "small" project of this type that a single person can serve multiple of those roles, it's a pretty daunting list.

I'd argue that it's precisely this sort of approach to SOA (and enterprise technology in general) that scares away and/or confuses the lion's share of consumers. Further, if you're not coming at an engagement like this with a set of tools and technology that decreases the need for all these different "specialists," then I think you're doing a disservice to your customer/partner. Heck, if your customer/partner has all those kinds of specialists at their disposal and/or has the money to have you staff them, then they are in a tiny majority of companies in the world.

These kinds of technology (SOA, BPM, EAI, ESB, et. al.) cannot and should not be the sole possession of larger or well-funded organizations...and telling people they need a team of 10 or more "specialist" roles (some of which later in the article we hear we'll need multiple) will only cement the idea that these things are just too complicated/expensive/rarefied for little ol' me. I don't think that's the message any of us should be sending, and I certainly hope that "experts" in this domain will start to realize that there are plenty of good solutions out there to help make it a lot less complicated than indicated in that article.

Make Way for Interactions!

A recent and recurrent thread of conversation within my organization has been the "so now what?" angle of SOA, BPM, ESB, EAI, etc. bordering on the philosophic. The whole "why are we doing all this anyway?" kind of stuff.

And, we are starting to solidify around the idea of "Interactions" and "Interaction Management" as a good way to describe what it is a lot of us are really doing and a lot of what people are trying to get done with all those three-letter acronyms. Isn't it really all about taking an outside-in look at how you want to interact with the outside world and making sure that your internal systems and processes are enabling that and interacting themselves? Sure, it may be web services enabling those interactions, and it may be SOA principles guiding how you do it, and there is almost certainly some BPM going on to make it work right...but it's really all about Interactions.

Interestingly enough, there are some other folks out and about talking about Interaction Management as "the next big thing," namely Mike Gilpin over at Forrester as one good example. This is really starting to make a lot of sense to me and I think we're going to start hearing an awful lot more about this. Stay tuned...

Build or Buy? Not so fast...

Ok, ok, so we've all been confronted with the whole "build vs. buy" debate...maybe even from multiple sides. I think one thing that this whole SOA/BOM/EAI/EDA and now Interaction Management progress has brought to light is that it may not be as simple as "build vs. buy" anymore.

Tech groups -- especially tech groups within a non-tech company -- are often tasked with trying to decide a)should we build it ourselves or buy something and then customize it to our needs, and then b)if we decide to buy, what product(s) should we buy? And, often groups that would want to buy but then get into the "b" branch there get overwhelmed by a given product or set of products and convince themselves, "You know what? We should just build this thing ourselves anyway, because we'll spend man years customizing this other stuff to our needs anyway."

A big problem with that is the question, "What about the business?!" Sure, the end result of that approach may be that you get a perfect fit for the given company...but it more than likely will be that it takes way too long to be delivered, doesn't work as advertised, and the business has almost certainly moved on to other initiatives and needs by the time it's done.

So, what does an enabling technology need to do to help fix this? While it may seem obvious, it's worth saying: it needs to provide both a foundation on which savvy tech groups can build as well as plenty of richness from day one that the business team can immediately sink their teeth into. By doing this, more SOA/BPM/Interaction Management initiatives will be successful, will be greeted more openly by business users (and that's who we're trying to keep happy here, right?), and ultimately do a better job of delivering on the promises we make about them every day.

HOA - Not just your homeowners association anymore.

While I'm not usually that excited about yet another acronym, I think the idea of HOA -- Human-Oriented Architecture -- is a fairly decent one. And, seeing as how one of my over-arching themes here is that talking to people about "SOA" isn't always the best way to get them jazzed up about SOA, the ideas from Joe McKendrick's recent blog post at ZDNet piqued my curiosity.

A couple good ideas there are 1)bottom-up pushing of enterprise initiatives is a difficult strategy, and 2)learning from the benefits of wiki-style mass collaboration might get us the mindshare we need to be successful.

I'll take that idea and run with it in the sense that I'd say we need tools that embrace that idea as well. If we need to have full involvement from business and IT to be successful in these kinds of initiatives -- and I'm fully convinced that we do -- then we need to give both constituencies the tools they need to collaborate effectively in the planning, design, implementation, and ongoing utilization and management of the resulting architecture. Further, I'd say that in an ideal situation all groups would even be able to use the same underlying tools...all via UIs that make the most sense to the way they conceive of the problem(s) they are trying to solve.

SOA and BPM Made Real - Take 2

Just a little more evidence that the concepts behind SOA and BPM can be put to great use in an almost "stealth" mode by presenting them in terms that the target audience understands, and not necessarily as "SOA" and "BPM."

In this podcast my colleague, Robb Duke over at Contact CenteRevolution, talks about how people in the contact center space can handle the underpinnings of SOA and BPM in a language all their own -- desktop unification/virtualization, multi-system integration, the universal agent, access anywhere, etc. In fact, Robb even has war stories of talking to the exact same person first in an attempt to "sell them" on SOA and BPM and failing miserably, but then talking to them about the exact same topics on their own terms and having great success.

Words to the wise: don't ever think one size fits all. Most people understand this adage when it comes to the solutions they deliver, but many fail to understand it when it comes to the positioning they use for those same solutions. You gotta make it real.