Enterprise architecture in Salesforce consulting, applying TOGAF (can we?)

It's been a while since my last post (work, life and holidays happened, among other things!), so I want to keep a lighter tone with this one (I think), at least it'll be less deeply technical than others.

This post will be about Enterprise architecture with a bit of methodology (just a bit), not entirely about Technical architecture, although that will also be a part of it.

First, some definitions from wikipedia and The Open group docs:

Enterprise architecture (EA):

Enterprise architecture is a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy

The Open Group:

The Open Group is an industry consortium that seeks to "enable the achievement of business objectives" by developing "open, vendor-neutral technology standards and certifications"

TOGAF:

The Open Group Architecture Framework (TOGAF) is a framework for enterprise architecture that provides an approach for designing, planning, implementing, and governing an enterprise information technology architecture. TOGAF is a high level approach to design

 TOGAF ADM:

The TOGAF ADM is the result of continuous contributions from a large number of architecture practitioners. It describes a method for developing and managing the lifecycle of an enterprise architecture, and forms the core of TOGAF

So, to sum those up, I'm going to talk about EA and how we can extrapolate it in Salesforce consultancy. I'll follow the phases of TOGAF ADM to explain how we can do that for different types of projects (i.e. single work stream and multiple work streams) and what the deliverables usually are (and can be) for each of these phases.

I'll be putting links to some of the TOGAF public docs at each step of the way, for those of you that feel curious enough to take a deeper look, as I won't be mentioning everything TOGAF entails.

Before I start, I want to say that I'm a certified TOGAF Architect and that's why I'm choosing to use ADM for this article, I'm afraid I might not be familiar with the many other frameworks that are out there, so won't be able to help with comparisons and so on. I also want to say that, being quite technical in my background, this certification opened my scope of interest and let me enter different conversations and gain knowledge about a side of the business I wasn't that much into before, so I highly recommend it.

Ok, introduction out of the way, let's jump in:

The following diagram shows each of the phases of TOGAF ADM and how they flow in a normal cycle. More info here.

 

Preliminary phase

The preliminary phase is the start of it all (obviously). It is where everyone gets together to define what the EA is and what it's going to look like, what's the framework to be used (ADM or otherwise) and what the principles are going to be.

I think for this phase we can be almost covered with my previous article on architecture principles. For the rest, we're going to be using ADM, and there's no discussion about that, everyone agrees!

More info here.

Single work stream

For a single work stream, especially in Salesforce projects, this is where we get together to explain and agree on the Salesforce specific principles and iron out any other considerations before we start even the discovery phases, if you're even doing such a thing. This probably doesn't fit in many single stream projects, as at this point only Sales people and AEs are involved, but principles need to be a thing that any consultancy must have, before starting any projects or anything else!

Deliverables: Salesforce specific architecture principles.

Multiple work streams

For multiple work streams, this phase is where we set the principles for both EA and Salesforce specifics. We'll be working with our client to even define what the work streams will be, as we don't know them yet at this stage. We'll also set out the governance bodies we (the whole enterprise) are going to have and the ways of working for the initial discovery phases and beyond. Think centre of excellence (CoE) setup, in Salesforce words.

Deliverables: EA and Salesforce specific architecture principles, CoE setup.

Architecture vision phase (Phase A)

Regardless of all other considerations, in my opinion, the main goal of Phase A is to get sign off and make sure the clients has budget set aside and guaranteed for the work we want to do!

For that, we need to come up with the vision of the capabilities that we're going to address, and for these we need to help the client get a valid business case. TOGAF comes with a great method to do this, by using business scenarios. 

You'll notice that this has a line to the Requirements Management phase (as all phases do). I'll cover that phase later on lightly (spoiler: after the preliminary phase, we're ALWAYS managing requirements).

More detail here.

Single work stream

In a single work stream consultancy project, I think of this phase as the period before discovery starts, mostly pre-sales: getting the requirements (or RFP, or whatever the format may be), super high level solution and estimates in the statement of work (SoW) and winning/signing the project!

Key deliverable: signed SoW.

Multiple work streams

For multiple work streams, I think this phase is still on the pre-sales remit, but it's a lot more complicated than the above. We'll need to do a full assessment of the capabilities needed, with the client deeply involved and hopefully paying for it. We'll run the business scenarios with them and produce a high level vision of (at least) the capabilities we'll work on, in order to define the different streams we'll be implementing. Within Salesforce projects, we'll probably need to know, with a good degree of certainty, the different clouds and products (including 3rd parties in most cases) we'll be working with for the future phases at this point.

Specifically important at this stage is to identify all the relevant stakeholders within our client's company, involving them since the very beginning, if possible. This is key, as we can start to identify who is "friendly" and who is not, what their goals are, getting insights of any internal politics and establishing the best way to manage them and keep them engaged. Ultimately, we'll need everyone to be on board, as we need to drive adoption if we want our project(s) to be successful.

Key deliverables: signed SoW for the next phases (discovery initially), high level architectural vision based on the agreed capability model, output from the business scenarios process and stakeholder matrix.

Interlude

At this point, we already have a signed off request for work (hopefully!), in both single and multiple streams of work, although they will mean very different things, of course.

Anyway, I wanted to clarify, in case it's needed, that my understanding of these following phases and pretty much all of what I'm mentioning in this post is merely indicative, every project is different. Everything is just based on my experience and the way I like to do these things, of course.

The list of deliverables for each of the subsequent phases can be very big, so I'm going to mention just a few that I think are more important, but feel free to check TOGAF docs, or add your own. Would love to learn about new ways of documenting things, hopefully making it more interesting for everyone!

The next 3 phases (B, C and D) will be similar in structure, but will deal with different angles of the architecture. They'll all include:

• Current architecture (optional)
• Target architecture
• Gap Analysis
• Roadmap components

Gap analysis and Roadmap components are specially important for projects with multiple work streams as they will usually map to the actual streams of work that are needed. 

For single stream projects, these phases are all commonly merged as a set of discovery exercises and are often much more informal than 3 distinct structured phases. Out of these discovery exercise you usually get enough solution design, data and technical architecture documentation and details to get started (hopefully a backlog to start in as agile way as possible). You'll also get a validation of the estimates provided on pre-sales and potentially a new SoW.

Let's proceed for the next 3 phases, focusing on multi stream projects or programmes.

Business Architecture phase (Phase B)

With the outcomes of Phase A, now we need to get the target business architecture, this includes:

• Current business processes and definitions (optional)
• Target business processes and definitions
• Gap Analysis for the business needs
• Roadmap components out of the Gap Analysis

Key deliverables: different diagrams (business process flows, actor/roles, functions, etc.), business requirements definition as outcome of the gap analysis and the definition of the roadmap components discovered.

More detail here.

Information Systems Architectures phase (Phase C)

With the outcomes of Phase A and B, we need to define the target Data and Application architectures. 

Data architecture refers to data models, relationships, definition and also governance and migration needs. Related to Salesforce, we'll also get detail on data volumes and limits, specific features and the needs that arise from those.

Application architecture refers to the needs for application resources, usually arranged in sets of features and solutions. In Salesforce, this usually means defining functional areas covered by a particular cloud, set of features or 3rd party product to the right level of detail to which we can carry on with a gap analysis and establish roadmap components, not to implementation level detail.

Both of these architectures are included in this phase, covering the usual steps:

• Current data and application architecture definitions (optional)
• Target data and application architecture definitions
• Gap Analysis for the data and application needs
• Roadmap components out of the Gap Analysis

Key deliverables for data: ERD, sharing and security documentation and data migration strategy and tools.

Key deliverables for application architecture: logical application architecture diagrams (software, roles and relationships), application definition documents and feature set definition when required.

Key deliverables for both: gap analysis outcomes transformed into roadmap components that include both data and application needs, adding to the business roadmap components from the previous phase.

More detail here.

Technology Architecture phase (Phase D)

With the outcomes of Phases A, B and C, now we need to get the target technical architecture (my favourite, as you might have guessed), this includes:

• Current technical architecture and definitions (optional)
• Target technical architecture needs and definitions, specifically on the following key angles:
• Technical standards and models to be followed
• Physical inventory of technologies and infrastructure within the right locations
• Establish technical needs based on the outcome of previous phases' roadmap components
• Configuration needs
• Needs for customisation
• Integration requirements and technologies
• Identifying and defining what TOGAF calls architecture building blocks (definition of functionality and how they may be implemented without the detail introduced by configuration or detailed design). These are started in previous phases, but finalised here
• Gap Analysis for the business needs
• Roadmap components out of the Gap Analysis

Key deliverables: different diagrams (systems landscape, infrastructure and communications, security, etc.), technical requirements definition as outcome of the gap analysis and the definition of the roadmap components discovered, iterating on the components found on phases B and C.

More detail here.

Opportunities and solutions phase (Phase E)

This is the phase where we take all the roadmap components identified previously, rationalise them and get them reviewed and approved by the right stakeholders. The main objective of this is to create project definitions out of these items.

More details here.

Single work stream

I don't think this phase applies to single stream projects.

Multiple work streams

Multiple projects are identified and converted into the different work streams that will be implemented.

Key deliverables: project feature and value definition for each of the work streams, in the agreed format.

Migration planning phase (Phase F)

In this case, I found it confusing at the beginning, because I tended to simplify it and think of data migration only. In reality, this is the phase where the different projects identified in the previous phase are placed in order, to form a proper roadmap and implementation plan of all EA needs. 

More details here.

Single work stream

The only extrapolation I can think of for this phase is the gathering and approval of the discovery outcomes and deliverables, definition of the scope, project planning, backlog prioritising and planning for the first implementation sprint.

Key deliverables: prioritised backlog, high level project plan, sprint planned and ready to start.

Multiple work streams

Multiple streams are placed in the right order of implementation, and signed off based on value added to the client.

Key deliverables: Architecture roadmap, migration plans, governance models, change requests and SoWs for each work stream, when required.

Implementation governance phase (Phase G)

As the name implies, this is the phase when the implementation is on-going, so the right level of governance and architectural oversight (EA, not just TA) needs to be in place.

More details here.

Single work stream

Normal project management, backlog refinement and sprint planning activities. Proper test strategy execution is included as well.

Multiple work streams

Centre of excellence should be acting in full swing at this state, as there can be many work streams occurring in parallel, so governance is key and quite hard to achieve!

Key deliverables (for both types): sign off of different stages of the project(s) and individual project contracts and SoWs, reflecting any change requests when appropriate. Finishing implementations in the right way is the key thing here, apart from getting paid, of course!

Architecture change management phase (Phase H)

In this phase, we tweak and/or establish the future change management process based on the one that's in place. It's definition was started in the preliminary phase and finalised in the migration planning phase F, the plan was effective and in use during phase G (all as part of CoE requirements). This phase also ensures our EA is up to date, finalised and valid or if there's a need to start a new ADM cycle to address only the gaps.

This is the last phase and it's on-going through all implementations outside of the cycle (it can slightly overlap phase G as well, it may not be extremely fixed one after the other, if required). This phase implies a continuous effort to keep the EA up to date, so it needs to be validated and run in an agreed frequency (either time based, needs based or milestones based that will be specific to each enterprise or industry).

More details here.

Requirements management phase

This is arguably not even a phase on it's own, as every phase has a component of requirement gathering and management (mentioned in a spoiler previously), so I won't get into it in a lot of detail. The objective is to capture needs in a specified and agreed format and use it throughout the full cycle.

More details here.

Wrapping up

To finalise, I want to mention again that all projects and programmes are different, all clients are different, requirements change and ADM cycles can be run as many times as needed, they can even be shortened and chopped in half, depending on outcomes of the preliminary phase, so keep an open mind, work together as a team with your clients and good luck!

Hope the post was helpful and insightful for you, as usual. Happy to get some feedback, suggestions, issues, anything you can think of.

Hopefully it won't be too long until my next post so see you all then.