A high level abstraction of a multi-faceted system communicates the principles in a straightforward way to non-technical stakeholders and ‘should’ give confidence that the shared concept will work.

Admittedly, SaaS moves the complexities of delivery a step away from customer concerns, but communicating the big idea is always essential.

This post was mentioned on Twitter by edlwarner: Does SaaS Diminish the Need for Enterprise Architecture? http://bit.ly/bK9zR via @AddToAny…

A high level abstraction of a multi-faceted system communicates the principles in a straightforward way to non-technical stakeholders and ‘should’ give confidence that the shared concept will work.

Admittedly, SaaS moves the complexities of delivery a step away from customer concerns, but communicating the big idea is always essential.

I like your site and especially enjoyed starting in the Lessons Learned section.

Jeff

Within the three categories you must answer three questions; Why is this a Priority for me?, What is Required of me? (this includes soft factor requirements like people/politics/policies and procedures), and What is my success criteria?

Think about it- a 3 X 3 grid all on one page to clearly show why an EA makes sense. The answer (by the way) also serves as a qualification tool for sales so they should willingly participate. In other words, if you can not ALIGN your proposal (in this case the use of an EA) with the priorities Requirements and Criteria of the key stakeholders, you can go on to the next opportunity.

There is a free downloadable short story at my web site http://www.knowledge-advantage.com. We’ve been doing this for 18 years so we have the scars! All the best.

Gene

I am of the opinion that the struggle to get buy-in for committing to EA in a sales organization is as hard as or harder than it is for the buying organizations. Enterprise Architects can still struggle to explain the value proposition of Enterprise Architecture, the ramp up is challenging, and demonstrable results can take a while. To use a health analogy: in most organizations the focus tends to be on “symptoms” (fix my immediate pain – aka this Qtr or FY results) rather than systemic “cures” that can lead to long-term competitive advantages. The later takes more commitment, but the yields are higher. My experience has been that sales organizations have an even harder time with programs that require a longer term focus or commitment.

So trying to do a first-of-kind EA deliverable in a sales cycle as you describe is bound to create “drag” and frustration. As the sales team found out, the concepts of EA are easier to grasp then execute. From the description, it is not clear if the architecture document idea came from within the sales team or was required by the prospect. If the later, where did the idea originate from? It appears not to have been part of the RFP (competitor?).

The bottom line, and as I suggest in the post, if a vendor wants to improve its competitive profile over the long term, they should take an in-depth look at EA.

Thanks again for your comments and good luck in your future sales cycles!

The question I have is how do you get buy in from sales? I worked in an organization where we introduced the concept of an architecture document. Unfortunately, the “architects” required an unreasonable amount of time to create the “architecture” documentation required as part of the deal. This frustrated the sales team and the customer. Because the presales team had no training in enterprise architecture, it required more time than normal to create the architecture document. The same happened on the implementation time. The time (and effort) required to create an architecture document was unreasonable.

Have you seen this? How did you resolve it? I look forward to your response.