Monday, November 10, 2008

Relationship-Centric Companies: The Serial

Ok, so I'm a bit too young to remember the age of "The Serials," but I'm going to steal that good idea. I recently co-authored a white paper that intends to describe what value Interaction Management and Interaction Delivery -- concepts I've blogged about here previously -- can bring to a company, and specifically what kinds of companies might best benefit from those concepts and from the software that supports them. And, I thought that instead of just linking to that white paper, or just embedding it all in one post, I'd try the old serialized approach.

To that end, today I'll start with an overview of the whole thing, and then I'll come back with portions of it over the next few days/weeks. Enjoy!




Through this "serial," I will talk about an emerging business pattern called Relationship-centric Interaction Delivery, provide examples of how this pattern spans industry sectors, and explain how the pattern brings value to a business’s internal relationships and their strategic relationships with partners and customers. I'll include brief case studies that describe how my company has used this pattern to achieve significant reductions in cost and time-to-value for our customer base.

By following along, I hope that you will get some insight into:
  • How the relationship pattern has broad applicability across different industries
  • That there are identifiable characteristics common to the relationship-centric pattern
  • That the relationship pattern represents businesses and affiliates engaging in and driving strategic interactions with their value-based investments (customers and business partners) in order to deliver recombinant business offerings to them
  • How software can facilitate the relationship-centric model and provide agile interaction delivery (so you don't have to do all this "without a net")
  • How relationship-centric companies can achieve quantifiable return on investment by intelligently applying enabling technology to address their needs

Friday, September 5, 2008

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.

Tuesday, July 1, 2008

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.


Monday, May 19, 2008

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.

Friday, February 15, 2008

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...

Friday, January 25, 2008

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.