Salesforce enterprise architecture

Salesforce enterprise architecture DEFAULT

Why Salesforce may not be a good foundation for building Enterprise Architecture?


Undoubtedly, the number of IT services and workflows that are becoming interlinked across platform boundaries, organizational boundaries, and devices, continues to grow. Some examples of these IT services and workflows include business-to-business workflows, IoT, cloud services, artificial intelligence, and other emerging trends. In these contexts, Enterprise Architects and Quality engineers enhance the necessary end-to-end attention to quality attributes. Integrating methods and tools from Enterprise Architecture (EA), IT service management (ITSM), systems/software engineering, information security management, etc. is, therefore, imperative.

Where in yesteryears independent actors acquired domain knowledge and acted on it in silos, today, there is a constant push to achieve IT/business alignment (ITBA). This collaborative process means that there needs to be a holistic consideration for:

  • Management issues (e.g., Business and IT strategy, risk management, etc.),
  • Design considerations (requirements analysis, system/software development, etc.)
  • Operative considerations (configuration, monitoring, etc.)

EA has gained traction as the disciplined, holistic and unified approach for managing the complexities in business and IT systems at a strategic level. Essentially, EA helps provide decision support for IT/business alignment (ITBA) to enterprise stakeholders (clients, employees, business manager, IT manager, Information manager, HR manager, project manager/project worker, logistics manager, financial manager, security manager, Chief Architects, CIO, CTO, and directors)

EA is also well-known for its model-based methodology, that covers a broad range of phenomena as highlighted above. The purpose of the EA models is to help the variety of stakeholders to:

  • Document and, therefore, understand a complex enterprise
  • Analyze the properties of current and future scenarios
  • Plan and design future scenarios and the path to that future
  • Communicate the current/future state of affairs to other stakeholders in the organization
  • Have a powerful decision-support tool.

EA standards is significant in enabling organizations to effectively manage business and IT resources

The use of EA standards is significant in enabling organizations to effectively manage business and IT resources, (networks, hardware, software, data, and people) and provide a comprehensive overview of the inter-relationships within an enterprise.

A good EA, therefore, considers the latest innovations in organizational structure, business processes, information systems and technologies with the definite purpose of enhancing efficiency, reliability, and timeliness. It includes the use of:

  • A standard language (which may consist of a duality of EA artifacts, both implicit and explicit)
  • Best practices for business processes (including an analysis of where processes can be eliminated or integrated)

Ultimately, EA should enable businesses to structure IT projects and policies to realize desired business outcomes that will allow the entire organization to manage disruptions and keep up with trends. Also, adopting EA should go beyond having a blueprint that describes:

  • What it is for you,
  • What it can do for you, and
  • How it can do it

To make EA work, you need to apply the blueprint/concept to a structure. Basically, besides the blueprint, you also need to start a process, educate people and assign roles, create products, get the products approved, and then use the products.

As such, EA mainly seeks to manage and maximize IT system qualities, business qualities and IT governance qualities.

IT-System Qualities

IT-System Qualities

Some of the well-recognized IT-system quality attributes that should be managed throughout the lifecycle of the software/system include:

Performance, or efficiency. How much work a system can perform and how fast in terms of scalability and responsiveness.

Interoperability or the ability of multiple components or systems to exchange information and to use that information.

Availability. How often a system is ready to deliver its services to its users.

Security. How well a system can preserve integrity, availability, and confidentiality, of its internal information.

Usability. How simple/convenient it is for a user to interact with and perform tasks in the system. It includes operability, learnability, understandability, and attractiveness of the IT-system.

Accuracy. The degree to which the IT-system produces precise and accurate data. (Determined by comparing output values with real/expected values).

Maintainability/modifiability. The ease with which an IT-system can be changed/adapted/modified to a changed environment, during its lifecycle. Its sub-qualities include integrability, portability, reusability, flexibility, and extensibility.

Suitability of an IT-system is the degree to which the functionality of the system supports the system’s intended work tasks. Suitability is contingent on the systems functional characteristics like adequacy, implementation completeness, implementation coverage, and specification stability.

Business Qualities

Useful Business Qualities

Useful business qualities to consider include:

Flexibility or the ability of a business (processes and organizational units) to adapt to changes in market conditions/requirements, e.g., demand, economic factors, politics

Efficiency or the ability to reduce time to accomplish business processes including manufacturing time, lead time, cycle time, work time, automation of work, etc.

Effectiveness is the ability of the business to produce what the market demands while spending minimal time on administration and paperwork

Integration and coordination or the ability of organizational units in a company to synergize, e.g., coordination of production, sales, and distribution units

Decision support or the capacity of a company to reinforce/enhance its decision-making process by making well-informed decisions, low uncertainty and high-reliability decisions, organization-wide accepted decisions, etc.

Control and follow up encompasses the ability of the business to monitor, document, evaluate, modify and re-use decisions/implementations

Organizational culture or the behaviors and value that contribute to the psychological and social well-being of the business including motivation, job satisfaction, stress, etc.

IT Governance Qualities

IT Governance Qualities

Some widely used IT governance qualities include:

Plan and organize. Addresses strategy and tactics, and is concerned with identifying how IT can contribute to the success of business objectives.

Acquire and implement. Addresses the realization of the IT strategy; identifying, developing/acquiring IT solutions; and implementing and integrating IT strategy and solutions into business processes.

Deliver and support. Addresses delivery of required services including service delivery; service support for users; management of data and operational facilities; and management of security and continuity

Monitor and evaluate. Addresses governance, monitoring of internal control, performance management, and regulatory compliance to keep/improve quality and compliance with control requirements.

What is Salesforce designed to do and how does it fit in EA?

Salesforce can manage and maximize several of the IT system qualities, business qualities and IT governance qualities that are necessary to implement enterprise architecture. At least, some Salesforce exponents certainly believe this to be possible. I concur with them, but only up to a point. Let me explain.

If you twist my hand and ask for a simple answer to the question as to whether Salesforce can be used as a foundation for enterprise architecture. I would say, yes. But…

The reality is not that plain and simple. Essentially, it depends on what your needs are.

Salesforce was designed and built to be a CRM before anything else and is the preferred CRM solution for many enterprises. Moreover, due to several Salesforce-related initiatives, (including Salesforce AppExchange and the recently purchased MuleSoft that is used to provide integration solutions), some enthusiasts consider building applications on the Lightning/ platform as a foundation for their enterprise architecture (EA).

Salesforce proponents believe that it can be used as a foundation for building EA because it has most of the essential pieces in place to be rapidly deployed as a foundation for EA. These advocates suggest that Salesforce can be adapted to the following core tenets of a successful EA methodology.

  • Business-value led. It provides a single platform that brings together several IT and business components (sales, marketing, customer service, automation, and analytics), all directed at enhancing business goals and objectives.
  • Pragmatic. It provides an executable roadmap that can be implemented in a relatively short time (months instead of years).
  • Minimum viable product (MVP). It offers an execution road map that is based on an understanding of the current state and an agreement of the future state. It, therefore, avoids analysis paralysis and the creation of complex documents that don’t add any value to the business.
  • Governance. It also solves the governance issue by allowing IT and business to speak a common language. The net effect is efficient dialogue and faster decision-making.

Despite these advantages of using Salesforce as the foundation for enterprise architecture, it is difficult to escape the fact that Salesforce also has its drawbacks as an EA platform. These drawbacks have to be considered when deciding whether Salesforce is suitable for your EA needs.

Drawbacks of using Salesforce as an EA foundation

Salesforce wasn’t built to be for EA

Salesforce was designed and built to be a CRM for sales management and not for EA. This means that integrating it into EA workflows can be challenging.

Limited options

With Salesforce, you have limited deployment options, data center options, and cloud options. This means that if a technology that perfectly suits your needs appears on the market, all you can do is hope to see if Salesforce offers the technology as well. Also, if you are in a country that isn’t near a Salesforce data center, then you will very likely have performance issues including system downtime and service interruptions.

Unnecessary functionality and excessive cost

It’s quite easy to purchase unnecessary/redundant Salesforce functionality that you might not even need. Worse yet, since Salesforce is sold on a subscription basis, you will have recurrent costs that accumulate with time and that are difficult to justify. Furthermore, if you need additional integration through web service APIs, you will still need to pay more.

Requires extra apps and developer customization

Although Salesforce is quite robust and powerful, if you need custom interfaces or additional functionality, then you can expect to use the services of a Salesforce developer to do the job for you. Over time, you will find that a complete or perfect solution will not only cost you a lot more in the long run, but it will lock you into a solution that becomes clunky as well. Also, once a company develops its own custom app on the Salesforce platform, they have to stick with Salesforce to protect their IT investment because the custom app is usually untransferable.

Regulatory concerns

Data privacy and government compliance requirements may limit what you can do with Salesforce. For example, Salesforce only has about nine data centers and yet some countries do not allow companies to have customer data hosted in foreign countries.

Other weaknesses of Salesforce as an application platform

Lightning Platform (formerly has the following drawbacks:

  • Although its configuration tools are simple to use, they don’t necessarily provide the flexibility desired to solve business needs
  • It offers minimal data visibility between application objects
  • Although out of the box reporting may initially be an advantage, over time, it is quite limited in its growth capabilities without adding too much complexity
  • It can’t provide workflows based on non-UI events
  • It doesn’t offer enhanced security features, e.g. there are several security issues with Salesforce web services

Salesforce AppExchange has the following drawbacks:

  • Requires multiple vendors
  • Although each vendor solution may work well on its own in the Lightning Platform, it may not do so working with other solutions from different vendors
  • Solutions in the AppExchange may require additional implementation services or further customization

Is MuleSoft viable for a long-term EA strategy?

Is MuleSoft viable for a long-term EA strategy?

One of the ways that Salesforce has tried to address deficiencies in its platform, with regards to enterprise architecture, is by absorbing MuleSoft. Through MuleSoft, Salesforce has gained an integration platform (Mule enterprise server bus and CloudHub), for connecting Accelerated Mobile Pages (AMP), SaaS, and enterprise applications.

Through the Mule enterprise server bus (ESB), IT can integrate/translate data into a format required by consuming applications and to manage the IT protocol as well. Also, it allows for IT orchestration. Through the Mule ESB, Salesforce can promote reusability of IT capabilities and its governance.

The problem is that, in a continually disruptive and changing environment, (where business users and customers frequently ask for changes), organizing source code around IT capabilities rather than business capabilities is not providing the long-term value that ESBs seek to address. This is why the ESB concept is quickly losing ground to the microservices concept or architecture style.

Even if you choose to use the Mule ESB, you may still come across some challenges related to ESB implementation including:

  • Difficulty in finding developers with excellent ESB skills since a wide variety of skills and experience is required.
  • Misuse of ESBs can lead to exceedingly complex architectures that are difficult to remedy

Suggestions for implementing Enterprise Architecture

Ultimately, it is difficult to suggest one thing in particular that will cover the needs of all enterprises. Enterprise needs and resources are different which means that what may be suitable for one organization may not be ideal for another.

Assessing your current state of affairs and considering future goals and then creating a well-thought-out EA methodology that suits your business is the best way forward to building a solid foundation.

Doing so will allow you to directly address and manage IT-system quality, business quality, and IT-governance quality necessary to build a successful EA. In some cases, Salesforce will be a suitable solution for building your EA. However, creating your own EA from the ground up will be the best choice in most cases due to the following advantages.

  • Build systems that are based on your needs/resources/strategy. This means that you should only build what you need and get everything right straight away. It’s a good idea to have an EA Product Calendar and EA Product Roadmap, including both AS-IS (current) and TO-BE (future) architectures.
  • Future-proof your needs and adopt new technologies that suit your organization.
  • You can better manage integration and assets including end of life assets
  • Respond to internal and external change faster
  • Dynamically scale resources based on current requirements
  • There is more flexibility to innovate
  • Gain a competitive edge through custom built systems and applications
  • Dynamically prioritize your business-IT needs and manage costs as your company grows
  • Efficiently manage complexity (increase or decrease complexity) based on value addition to the enterprise
  • Have as much control, clarity, and insights that you need because you can better manage licensing, dependencies and interrelationships.
  • Learn from your own mistakes, improve processes and become more efficient over time using your own tools.
  • Gain more control of your organization’s customer journey; processes and services landscape; and business capabilities map. You also have more control to build on insights gained in these areas over time.
  • The bottom line

Suggestions for implementing Enterprise Architecture

From our twenty-years of experience in project implementation, I can attest that Salesforce is not just a robust CRM platform but is also a worthy option for basing your enterprise architecture. The robustness and convenience that it offers make it a useful alternative to consider especially if you want to deploy rapidly. Nevertheless, it is inescapable that several other solutions were purpose-built for EA.

Ideally, the best EA solution is one that has been built for EA from the ground up. Developing your own architecture or at least exploring and adopting a platform that was created with Enterprise Architecture in mind is the best choice to make in the long run.


Integration Architecture for

Posted on November 27, 2014     2 Comments

This article was originally published for DeveloperForce on November 26, 2014.  See the following link:


As a Architect it is your role to lead your company in the evolution of it’s Integration Architecture. A good architect must understand both integration architecture and integration patterns.  The difference between the two is analogous to designing the highway vs driving cars on the highway.  The Salesforce1 Platform offers architects and developers a wide array of integration technologies and recommended patterns (the cars); however without the correct Integration Architecture and technology infrastructure (the highway) your projects and solutions will be at risk for performance, scalability, data integrity, and many other problems.  This article will introduce you to the components of an effective Integration Architecture as well as walk you through a reference design similar to many of my Enterprise clients.  Hopefully this article will be used together with the official Salesforce Integration Patterns guide when architecting your solutions.

What are the components of a good Integration Architecture?

The Integration Architecture aligns the Business Strategy with Technical Capabilities

The best Salesforce Architecture’s are not based upon incumbent technology, singular architecture approaches, or corporate politics.  The best Salesforce Architecture’s are based upon DELIVERING BUSINESS VALUE.  What this means for the architect is to focus on what are the business’s requirements, roadmap, and needs for which you will offer technical capabilities.  In other words – you need to see where the business wants to drive, and figure out which highways and roads are necessary to support the amount of traffic.  Idealistic architecture (for example 100% Services Oriented Architecture) may cripple your ability to provide the capabilities needed by your business when they need them.

The Integration Architecture supports a mix of batch processing and real-time services middleware

Good architects have learned that the best integration designs supports both batch and Service-based patterns.  This means you have multiple types of middleware at work.  I have had clients that had 3-4 different integration platforms in their architectural landscape.  This is because not one solution ever can effectivly meet ALL your requirements, and once again the idealistic architecture’s are not as important as supporting the business’s needs.

The Integration Architecture is based upon Business Service Level Agreements (SLAs)

A mature organization and architect will attempt to define SLAs for data and process integrations.  These SLAs have an important role on projects as they may radically affect the chosen technology and integration pattern.  The SLAs should be based upon real business needs (sorry – not everything in life needs to be real time) that help define the non-functional requirements.  If you only need to drive a few miles you do not NEED a highway.  However if you are going on a road-trip I hope you aren’t taking side-roads!  Define your solutions based upon your business’s service level requirements.

The Integration Architecture has a clearly defined standard for applying different Integration Use Cases

As your landscape evolves and your expertise matures, the goal is to define a set of capabilities and standards for all integrations at your company.  Each project should not have to define when and where to use what technologies, how and when to authenticate, etc.  These architectually significant designs should be standardized for your enteprise.  This is where a Center of Excellence or Architecture Review Board comes into play.  Each project should be subservient to a higher integration architecture authority.

A Typical Enteprise Integration Architecture

Let’s take a look at a reference Integration Architecture.  This may or may not look like your existing landscape – however this reference is based upon years of work at many Fortune 500 companies.  The reference design also does not recommend one technology vendor or solution over another – rather the goal is to understand the technical capabilities that you can (and probably should) consider as your landscape matures.

Reference Integration Architecture

A Reference Integration Architecture

Let’s take a look at the most common integration use-cases and how they apply to your Integration Architecture.  The direction of the arrows in the reference model is not necessarily the way the data is moving, but rather the way the integration connection is being established.  This is a critical aspect of Integration Architecture as it pertains to your security and any real-time requirements.

Cloud-to-Ground ( Originated)

In Cloud-to-Ground use cases you are attempting to push a transaction (message or data) from Salesforce into your On-Premise infrastructure.

Capability #1 – The originated message is relayed to a DMZ (demilitarized zone) service end-point.  This could be a firewall, a services gateway appliance, or reverse proxy.  You must work closely with your security team to define this layer as opening the corporate firewall to inbound web traffic is a high security risk.  This is where much (if not all) of your security authentication from occurs.  Whitelisted IPs, two-way SSL, and basic HTTP authentication are some of the ways to authenticate Salesforce into the DMZ layer.

Capability #2- The message is relayed from the DMZ security zone into the trusted On-Premise infrastructure.  The message is usually destined for a Enterprise Service Bus (ESB) and durable message queue.  The ESB also would handle any transformation, mediation, and orchestration services required by the detailed integration requirements.

Capability #3- Depending on your Enterprise Architecture the ESB maybe pushing the message into the SOA infrastructure.  These web-services are providing consumer agnostic data and business process services to the Enterprise. can become a consumer (and later a producer) of these SOA services.  By re-using existing SOA web-services you can save your project a lot of time and money as oppossed to integrating directly into the source system.  If you do not have a SOA layer your project maybe responsible for integrating directly into the legacy application.

Capability #4- Another key capability for mature Integration Architectures is for some sort of On-Premise database access.  This maybe a standalone database or part of a more formal Enterprise Data Warehouse (including an ODS – an operational data store).  Most commonly (but not always) in a Cloud-to-Ground scenario this transaction would be a database READ. can read data from the database in real (or near-real) time.

Ground-to-Cloud (On-Premise Originated)

In Ground-to-Cloud use cases you are attempting to push AND pull data from Salesforce from your On-Premise infrastructure.

Capability #5 – A mature Integration Architecture should be handling all of the real-time calls into Salesforce from the ESB.  However if you do NOT have an ESB, this step would occur from each separate application requiring access to Salesforce.  From a security stand-point it is much better to handle all of the calls to Salesforce from a centralized integration middleware.  You can use oAuth or user/pw session based authentication to Salesforce.  The middleware may already have a session with Salesforce so that you don’t need to log-in again for every transaction.

Capability #6 – Many integrations can be accomplished in a batch design.  This is often the cheapest and fastest way to get data in and out of  I would recommend a robust ETL solution is necessary for all Salesforce environments.  (This maybe as simple as Salesforce’s Data Loader Command Line Interface).  The role of the ETL is to move large data volumes using the Bulk API where possible.

Capability #7 – As a architect you have a responsibility to your company or client to off-load your Salesforce data into a replicated copy.  My argument for this is that Salesforce’s database is not likely to have outages or lose data, however you and your team are VERY likely to break your own data via user error, bad-code, or run-away processes.  By replicating your data off-line you now have the power to restore data to an earlier state without engaging Salesforce (who may or may not be able to restore it exactly as necessary).

Capability #8 – The ETL is also responsible for moving data in and out of your database infrastructure.  Often data is necessary to be staged in Salesforce (Accounts for example) from the EDW.  Also pulling data down from Salesforce into your EDW maybe much easier when done using batch processing patterns.


Capability #9 – If you have multiple orgs (see my article on multi-org strategy) you will often have the need to integrate between the Orgs.  Salesforce makes this (sometimes too) easy via Salesforce2Salesforce.  You can also directly contact another Org via RESTful web services integration.’s road-map includes the ability to consume other org’s data via OData which may also be a good way of providing read-only access across your org landscape.

Capability #10 – Salesforce’s robust integration technology makes it very easy to integrate point-to-point with other systems.  While this would be recommended for some solutions (Google Maps mashups, etc) I would recommend staying away from this design in large enterprises.  The more that Salesforce is made to be the hub of integration activity, the more time you will spend building, maintaining, and troubleshooting integrations as opposed to building new business value.  This is a trap I have seen many companies fall into.

Capability #11 – Rather than using to be your hub of cloud-to-cloud integration activity many companies have moved towards Cloud based Integration-as-a-Service packages.  While not true ESB’s per se, many integration vendors have started providing cloud based solutions for managing your cloud-to-cloud use cases.   Because these solutions are specifically tailored for (and other popular SaaS vendors), the time to build and deploy an integration can be radically reduced as opposed to using the ESB.

Cabability #12 – The cloud service bus’s can handle service mediation, transformation, routing, error handling, etc to your other cloud based end-points.  Having to build durable and resilient integration solutions inside of Salesforce can be expensive and very complicated.  Middleware should be used where and when possible.

Cabability #13 – Some companies prefer to broker all integrations through their ESB, including Cloud-to-Cloud use cases.  My warnings here are this: the cost of highly resilient ESB’s can be EXTREMELY high.  If the service levels between and Workday, for example, must go through your on-premise technology, you maybe shooting yourself in the foot.  Now your “Cloud” solution is piggy-backing on the same technical infrastructure, cost, service levels, and release timeline of your On-Premise solutions.  Tread lightly and make sure to design your Integration Architecture first and foremost about delivering BUSINESS VALUE.

In Summary

I was previously an Enterprise Architect working with Service Oriented Architectures before becoming a Certified Technical Architect.  When I was first introduced to Salesforce I was shocked to see either a 100% dependency on batch integration technology or a 100% reluctance to use anything but Real-Time services design.  However one of the reasons I enjoy what I do so much is that I have learned that there is NO GLASS SLIPPER in Salesforce Integration Architecture.  One size does not fit all and no one solution can be the best for all or your requirements.  It is your responsibility as the architect to analyze, recommend, and implement a variety of integration capabilities that will enable your team, clients, and company to realize the powerful transformation of moving to the Salesforce1 platform.

  1. Hydac usa locations
  2. Park bench ebay
  3. 370z single exhaust

Building an Enterprise Architecture with

I’m a huge fan of the SFDC platform. It has the potential to transform businesses if implemented and managed correctly. Unfortunately I’ve seen many companies come up short when trying to reap value from Salesforce. There are countless reasons for this but here are some of the top reasons I’ve seen:


  1. No organizational vision or direction for the company’s use of Salesforce
  2. No roadmap and product management strategy that ties the platform’s use to corporate goals.
  3. No formal architecture, governance or change management strategy leading to an evolutionary design of either silo’d functionality or a mis-use of multiple Salesforce instances.


  1. The original implementation was delivered with little-to-no technical understanding by the customer.
  2. A lack of understanding between how and when to use configuration vs custom code.
  3. The implementation consultants delivered “functional value” only and therefore lack any standards in the configuration design and coding layers.
  4. There are no patterns, no modularization, and no chance to extend the functionality without significant refactoring.
  5. Test coverage is completed only as an after thought and lacks any kind of design or assertions.  There is a high risk you will break something when you change configuration or code.
  6. Lack of any forms of living documentation that capture your design and the reasons for that design.


  1. Unwillingness or inability to retire legacy systems has kept people from using the system.
  2. Lack of training or communication to end users
  3. Data Quality in the new system is low and the outputs of the system are not trusted

So how do you prevent these types of issues?  How do you fix them if you are already a victim of this problem?  My recommendation to you is this: Build an Enterprise Architecture with

How do you do this?  It is not easy and it will take time, money, and platform knowledge.  But if done correctly Salesforce can become a differentiator for your business.

This post and the ones that will follow it will walk you through the process of establishing an EA for Salesforce.  The main framework I am using is the TOGAF Architecture Development Methodology.  If you are not familiar with TOGAF, I recommend reading up a little on the framework.  TOGAF is an approach for designing, planning, implementing, and governing an enterprise information technology environment and is an open standard of The Open Group Architecture.


The TOGAF v9.1 Architecture Development Methodology from The Open Group

Throughout the post I will follow the phasing of TOGAF and point out some relevant questions and considerations as you shape your Salesforce Architecture.  That being said here is roughly the process you will follow as you build your plan:

  1. Define Your Architectural Vision for Salesforce
    1. Who are your stakeholders and your business goals?
    2. What are the corporate goals that will influence your vision?
    3. What are your architectural principals?
    4. Where is your architectural repository and how will you manage your artifacts?
  2. Design Your Business Architecture and Strategy
    1. What Lines of Business will use Salesforce?
    2. What are your business requirements?
    3. What business processes will be implemented on or influenced by SFDC?
    4. What building blocks of your business will be built on SFDC?
    5. What is your org strategy?
    6. Who are your actors and possible license choices?
  3. Design Your Information System Architecture
    1. How do you design an Application Architecture on SFDC?
    2. How do you design a Data Architecture for SFDC?
    3. What is your application rationalization plan?  What will be added or retired with SFDC (and when)?
    4. What is your Gap/Fit and what will you do about it?
  4. Design Your Technology Architecture
    1. What is your integration architecture?
    2. What is the right architecture for custom development?
    3. How will you manage your technical environments?
    4. What are your technical risks and how will you mitigate them?
  5. Design Your Implementation plan
    1. What is the right methodology to use?
    2. What is your SFDC Architectural maturity?
    3. What is the appropriate release strategy?
    4. How do you build a roadmap?
  6. Plan your migrations
    1. What is your Cost/Benefit analysis for each release?
    2. What are you project dependencies?
    3. What is the right deployment strategy?
    4. What is your test strategy?
    5. What is your data conversion plan?
  7. Design your governance plan
    1. What groups will you need to integrate your efforts?
    2. How do you establish an effective CoE?
    3. What is an Architecture Review Board?
    4. How do you setup a system administration model?
    5. How do you manage your vendors?
    6. How will you ensure adherence to your architectural design and standards?
  8. Define your Change Management Plan
    1. How do you effectively manage change?
    2. What types of changes can be made in production and by who?
    3. What types of changes should be made in a project vs bug fix?

My recommendation would be to walk through the list in order and try to answer all of the questions at least once – to the best of your ability at the time.  Then return to back to the first section (architectural vision) and start to refine into a deeper level of detail.  TOGAF is cyclical and so too is your design and implementation of an EA for SFDC.  It follows the concept of continual improvement that will evolve each time you iterate through the cycle. So get busy and build out your EA for SFDC. Your users, your technology teams, and your business stakeholders will thank you for it.

Like this:



Salesforce Lightning Platform Enterprise Patterns - Apex Enterprise Patterns


Enterprise architecture salesforce


Salesforce and Architecture Part 1


Now discussing:


859 860 861 862 863