Solution Architecture

Keys to Successful Solution Architecture

Making the right solution architecture decision isn’t easy. “The menu” of potential solutions for your particular situation can be downright overwhelming. These decisions often have a dramatic impact on your ability to stay profitable and competitive; capital investments are substantial; switching costs are high, and opportunity costs can be even higher. There is a sea of software, hardware, and services out there to consider.

“Should we build it or buy it? Run it in-house, or put it in the cloud? Use a best of breed point solution or a comprehensive app suite? Does it have the features we need? Can we customize? How much help will we need to implement and maintain? What’s the real total cost of ownership?”

Miller Systems has assisted a wide array of clients to make sensible, cost-effective solution architecture decisions. Here’s what we’ve learned through substantial real-world experience:

• Don’t buy or build any solutions until you have clarity about the intended experience. Be mindful about how that experience might be driven by or dependent on your existing assets and systems.
• Use free or inexpensive trials to perform proof of concept prototypes. Getting “hands-on” is always useful in validating vendor claims and gaining a better understanding of what you’re buying.
• Be realistic about total cost of ownership. While an annual 20% support and maintenance fee from a software vendor might seem high, the cost of maintenance and support for “homegrown” software can cost at least as much – and be far more challenging to predict and manage.
• Don’t over-customize packaged solutions, especially where core features are concerned. Make sure that the customizations you do decide to make aren’t affecting your ability to keep the packaged parts current. Nobody wants to be 3 or 4 releases behind on their software because of a custom feature that someone decided was “top priority” 5 years ago.
• Be realistic about what your internal development resources can reasonably handle. Consider how they’ll need to adapt and evolve if a packaged solution replaces a “homegrown” and maintained solution.

Does Any of This Sound Familiar? Get In Touch

• I’m trying to deliver a new web site/intranet/portal for my customers/partners/employees. We have a pretty good idea about what we want to deliver, but we’re not so sure about the platform(s). We need help to make a good decision.
• We love the idea of “the cloud”, but how might that affect the security of our information? If we have a falling out with the cloud vendor, how locked in are we? What if they go out of business or lose our data? How quickly can we realistically recover?
• ECM, DM, DAM, WCM, CRM, AMS, BPM…I’m overdosing on acronyms! I need to sort out which pieces are appropriate for my project and my people.
• We’re having heated debates about whether we should develop our own software or buy it off the shelf. Is it all or nothing? Is there some middle ground?
• The marketing department wants package X, but IT is adamant about package Y. Which one is right for us? Why? How do we get the answers?
• We thought we bought the right software but now, deep into the implementation, we’re finding huge functionality gaps. It’s clear we overlooked some things in our initial plan. How do we avoid making the same mistakes again?
• We have lots of software that works perfectly well. Now we need to add some functionality that our current tools don’t provide – and won’t. We don’t want to rip everything out. Isn’t there something out there that will safely integrate with our existing systems?