Jeff Bills

Fig. 1 Why SaaS - Saugatuck Technology

This conclusion would be quite incorrect.  There are many mission critical functions the Enterprise Architect would still support with regard to helping the business accurately evaluate and successfully deploy a SaaS solution.  A short list includes:

• Business Architecture – you still want to capture the business drivers, shareholders views, business process maps, value chains, etc.  Gaps in the existing enterprise solutions need to be mapped to the SaaS solution and analyzed for completeness.
• Information Architecture – how does the SaaS impact data flow? Reporting and Analysis?   Data as an asset?
• Integration Architecture – how will this new “cloud based” system interoperate with on-site systems?  Partners? Customers?  What is the impact on your integration principles and strategy / road map?
• Operational Management – everything from security and risk to quality of service, communications architecture and SLAs.

Tip: You will want your EA practice to be an integral part of your procurement process (see this earlier post) as well as monitoring the solution as it changes.  The SaaS vendors / solutions are not standing still. Their architecture and capabilities change constantly.

In some cases the SaaS solution providers have Enterprise Architects on their staff to assist with providing the details your staff needs.  One company doing this today is Workday. Not only does this help, it can be a point of differentiation.

I look forward to comments and feedback.  Post here or e-mail me at jeff@jpbills.com

Working Together Teamwork Puzzle Concept

If you have a problem, do you want to be-labor it or solve it quickly?  Anyone who has been part of a major IT purchase (whether from the buyer or the seller’s perspective) knows just how slow, resource intensive, expensive and fraught with risk such an undertaking is.  Good Enterprise Architecture programs can expedite the process and deliver good decisions.

While there is a shared objective in understanding the buyer’s pain and seller’s solutions, there is not a common framework for exploring these. Enterprise Architecture can be this framework. Most approaches to enterprise architecture focus first on the business drivers (needs, expectations), have governance processes (principles, pains, roadmaps), and institutionally normalized vocabulary and artifacts.  If a major (or minor) purchase is moving forward, the drivers and artifacts surrounding it should already have been surfaced.

Tip: Make these Enterprise Architecture elements a core part of your selection process and model.  Leverage your Enterprise Architects and your existing EA program / process.

As discussed in my last article, sellers have a lot to gain by adopting good Enterprise Architecture programs.  Sellers will still have to apply their sales methodology, resources and acumen to the opportunity.  They still have to differentiate, but my experience has been that this type of “hard” content is much desired by buying organizations and would offer substantial differentiation.

Tip: Involve your pre-sales Enterprise Architects in your opportunites as early in the process as possible.

Sellers and buyers can use their respective EA practices and content as a communications and process bridge / catalyst.  This will provide for more transparency, reality, and less spin.  Additional benefits would include more predictable transitions from purchase through implementation.

Please take a minute and fill out the three question survey below. I look forward to comments and feedback.  Post here or e-mail me at jeff@jpbills.com

Very few IT vendors leverage Enterprise Architecture as they define, develop, market and sell the solutions.  Yes, there are many aspects, components or artifacts of an EA model in their engineering practices.  Architecture discussions abound in vendor processes / content (normal) but I have yet to encounter an organization that has an EA community spanning product management, development, marketing and sales.  (I would like to hear your feedback on this, post here or e-mail me).

The value propositions for Enterprise Architecture would be similar to those for the buying organizations: better alignment of product development efforts to the customer realities, better utilization of resources, etc.  I believe there are significant additional payoffs though is in the ability to market, sell, implement and sustain their products.

Extending the Enterprise Architecture program into marketing, sales and implementation completes the product development cycle (or architecture development cycle).  There is continuity, consistency, and repeatability that could extend across the vendor product portfolio.  The ability to communicate vision, drivers and realities of the product architectures and capabilities would also be enhanced.

Tip: Engage your Enterprise Architects in your marketing, sales and implementation strategy and execution.  If you don’t have EAs, develop them (and yes, this takes a long term commitment).

Buying organizations with good Enterprise Architecture programs have a real potential advantage in the buying process.  They have defined their architectural principles, they better understand their current challenges (governance processes), they have processes for introducing and managing change (business & technical)

Tip: Engage your Enterprise Architects in your buying process.  They can both streamline and improve the efficacy of your evaluation process.

Please take a minute and fill out the three question survey below.  I look forward to comments and feedback.  Post here or e-mail me at jeff@jpbills.com