Working with our customers day in and day out, I tend to get a sense for what the language barrier is between someone in the vendor role against someone who is in the buyer role.
You probably won't be shocked that what may sound like simple language can get quickly confusing, misunderstood, and outright tuned out by either side of the aisle.
The point of this post is to attempt to dispel the misunderstanding behind what a solution architecture (at least in our context) is. If you're not interested, or don't work with vendors much, stop reading now, and know I won't be offended.
Alright... Since you're still reading I can only assume that this has caught your attention, and you're interested in learning more. Let's move on then!
First a little background...
The concept of a solution architecture has been over-used since I first heard it back in 1998 when we were putting in firewalls and wanted to design the most effective way to implement.
Over time the term has become widely over-used to the point where meaning is largely lost... and sadly most people on the buyer side of the aisle think it's just some marketing term, or a way to get you to buy more of whatever widget is being sold.
While I admit that the term has been tarnished, but I assure you that there is still value in it.
I've recently started using it more as my organization evolves. We've always been a "way more than just software" type of vendor - but putting words to practice has been this group's mission for a while now, and it's refreshing frankly.
What is a 'solution architecture'?
Alright then, if we're to pull the tarnish off the phrase, we need to give it a solid meaning that has substance and value. A quick check of the Internets reveals what I've already suspected - we have a great definition to start from:
Solution architecture in enterprise architecture is a kind of architecture domain, that aims to address specific problems and requirements, usually through the design of specific information systems or applications.
Solution architecture is either:
- Documentation describing the structure and behavior of a solution to a problem, or
- A process for describing a solution and the work to deliver it.
So Wikipedia knows best, once again. Our definition of a solution architecture is exactly those two bullet points above. And it starts by asking one critical question... "Why?"
Yup. We ask "why?" Let me be outright about this- if someone tries to tell you what you need without first asking why you're asking for it... fire them.
How can a electrician tell you what's wrong with your house's wiring without first asking you what type of home you live in, who built it, when it was built and other basic seeding questions.
Why should this be any different for your Software Security Assurance program? You can't reasonably expect to succeed with a vendor provided solution to a problem you haven't laid out and defined.
What you should expect next is a series of interviews, in-depth probative questions, analysis and a sprinkle of industry experience and expertise. In proportion and in the hands of a true industry expert what you will receive back is a prescriptive plan for execution... more than that, a plan for success.
Even more importantly, it's a plan that outlines success by your definition of success, within your organization's parameters, timeline and resources. How'd you like them apples?
What's the big deal?
The big deal is that many organizations simply dismiss this all-critical step as part of the sales motion. I guess I can't blame those who dismiss this opportunity... I've seen some bad solution architectures in my time.
Heck, I've seen solution architecture that were delivered independent of the customer, from marketing slides, or by someone who had no idea what they were doing... and that all goes to tarnish the true power of a great solution architecture.
Look, I'm not saying everyone's an expert... and I don't want you to think that I'm trying to sell you on my methodology (yes, yes these are the droids you are looking for!), or that what we provide is necessarily something magical.
My goal is to make you aware that if you're not taking an opportunity to interact with your SSA vendor on this deep level... you're doing yourself and your organization a disservice. Honest.
Cross-posted from Following the White Rabbit