5 Reasons to Request Reference Architecture

It’s 9pm on a Thursday night and you’re still at your work desk. You know the deadline for your email system overhaul is looming, but you are dreading the process of selecting a new email partner to entrust with your 500,000 customer mailboxes. You have been in the CIO role long enough to remember the nightmares that ensued the last time your company switched vendors, so you don’t want those mistakes repeated. However, apart from the usual suspects (such as security, reliability, cost and vendor rapport), you are not sure what else to look for when selecting your next email partner and you’re keen for ideas.

If that’s the case, our suggestion, based on 20 years of email experience, is to ask shortlisted email vendors to see their reference architecture.

“A reference architecture in the field of software architecture or enterprise architecture provides a template solution for an architecture for a particular domain… based on the harvesting of a set of patterns that have been observed in a number of successful implementations. Further it shows how to compose these parts together into a solution… A reference architecture often consists of a list of functions and some indication of their interfaces (or APIs) and interactions with each other and with functions located outside of the scope of the reference architecture.” Wikipedia

Some companies, such as Microsoft, Dell, VMware, Pivotal, Red Hat, Cloudera and the United States’ Department of Defence, share their reference architecture documentation online, with Docker (a software development company providing containers) sharing an impressive twelve reference architecture documents on their public website.

However, most companies do not provide reference architecture on their public websites (which is understandable, given the perceived value of the documents as company assets), so, here are five reasons to request an email vendor’s reference architecture, before you decide on your next large-scale, email solution partner:

 

1. It’s an indication of quality and best practice

Putting together a comprehensive, reference architecture document is no small feat. Done properly, it involves a widespread internal commitment for all teams to work together (for example, CEO/Management, DevOps, Service Delivery, Customer Support, Engineering, Quality Assurance, Marketing, Sales, Innovation, Human Resources, Accounting and potentially more). Then, many conversations between teams to articulate current processes, components, workflows, requirements, analyses, knowledge gaps, areas for improvement, and so on. It chews valuable resources that could be diverted elsewhere, so in all honesty, most small (and some even some large) email players don’t even bother.

The actual process of internal teams joining forces to articulate (or update) their reference architecture document can be a positive indication that you are dealing with a high quality, best practice, email company. This is because the internal consultation and rigorous testing process shows a strategic commitment to: intimately understanding current processes and requirements; challenging internal assumptions; analysing future business requirements; solving problems across teams; and facilitating long-term process improvement.

 

2. It ensures clarity from your email partner

When email is not your core business, you neither have the time nor inclination to personally research the intricacies of how email should work. You need your email vendor to clearly spell out how their email solution works and specifically how it solves your email problem. The clarity of a reference architecture document can give both parties a crystal clear understanding about the proposed email solution, from which you can then springboard into a discussion about how/whether that solution will meet your needs.

Tip: If your email vendor says their system is too complex to explain, maybe their system is also too complex to maintain?

 

3. It gives a common vocabulary to your internal team

Liaising with external email partners always carries the risk that internally, your team members come back with mixed messages, which then get disseminated into even more mixed messages across your organisation. With a clearly defined reference architecture document, these risks are lowered, because processes are clearly documented and easier to share without confusion.

“Architecture provides a common language in which different concerns can be expressed, negotiated, and resolved at a level that is intellectually manageable even for large, complex systems… Without such a language, it is difficult to understand large systems sufficiently to make the early decisions that influence both quality and usefulness…” Source

A reference architecture document can also improve internal communication generally, because it helps all internal stakeholders to have the same architectural mindset.

 

4. It can reduce delays and poor decision making

If a company has already articulated their processes, they do not need to reinvent the wheel for each new customer, project or document. This can save countless hours of initial research and set-up time on both sides, which in turn, can result in significant cost savings for both vendor and customer.

Paul Reed, a former Software Engineer and Network Manager at IBM in Ohio, United States, recounts:

“Many projects I encounter spend an inordinate amount of time researching, investigating, and pondering architectural decisions… A project that proceeds without reference information will not necessarily fail; it will just require considerable effort on the part of the project team that could be spent better elsewhere…”

“…reference architecture [ ] can dramatically reduce the number of incorrect technology decisions and increase the likelihood that a project will get off on the right foot. Such frameworks have been a hallmark of successful organisations since the early days of distributed Client/Server applications; as systems grow in complexity, the requirement becomes more imperative.”

 

5. It can help with compliance

If you have external regulatory bodies and/or internal quality assurance teams to answer to, a fully detailed reference architecture document (with both text and explanatory diagrams) can help with compliance requests to understand how your email system works and what processes your email partner employs to ensure that it stays working.

 

 

An insight into atmail’s updated reference architecture

By Glen Lynden, atmail’s Director of Service Delivery

Having served email clients across the globe for 20 years, atmail has long provided prospective customers with both the necessary documentation they’ve needed to understand how atmail works, as well as a comprehensive Help Centre to help them best implement our email solution. But it’s only just recently that we embarked on a project to upgrade and expand on our reference architecture.

The objective of our recently-updated reference architecture was to:

• provide a more detailed design of each component which makes up the overall architecture;
• better highlight all areas for consideration, prior to re-articulating our architecture; and
• produce improved reference architecture that could be used for our internal DevOps team, other internal teams, as well as satisfy requests from our large scale customers.

We knew the content, but the updated layout and presentation were important, so our initial discussion was agreeing the sections for our new document and allocating modules to team members to start drafting the content. After many inter- and intra-team discussions, several iterations and peer reviews, a final draft of our updated reference architecture document was produced and sent around our teams for feedback and improvements. Our focus was, “put yourself in our customers’ shoes” and full credit to all of our teams for their suggestions and improvements.

New this time around, we also added a Compute Quota Calculation Tool. A spreadsheet was developed showing the different modules which make up an email system and test results were utilised to develop the tool. We added fields to enable customers to adjust it to meet their requirements. The ability to cost the platform was also included. Finally, the tool was tested (and retested) for accuracy across differing inputs.

The result? Yes, it took a significant time and resource investment, but atmail now has an updated reference architecture document and calculation tool to better serve our customers. (A personal thank you to everyone at atmail for your support in this process.)

Invitation

If you’re a large scale telecommunications or hosting provider who is looking for your next trusted, email partner and you’d like to chat to us about our reference architecture document, we’d love to hear from you here.