Hi Architects!
In this post I would like to lead you through my thoughts and experiences on how to emphasize and place the value of EA work within SAP projects, either towards internal stakeholders or clients. Mind you this is more of an unsorted list and not meant to underline a sequence or priority and more based on my experience in EA within the context of SAP projects (I am sure some of this can be abstracted well for other non-SAP use cases too, however surely you won’t deny there is a certain uniqueness to SAP projects).
I greatly appreciate your inputs towards your own experience, or any way you find yourself agreeing or disagreeing to drive the discussion.
Consideration #1 – Greenfield vs. Brownfield
A brownfield client will have a set of experience with SAP products (good and bad) that also comes with expectations as to what the goal should look like and what typical roadblocks could be. For this context it is especially important to keep in mind what the overall disruption to the remainder of the existing systems and processes means and how those can be integrated.
How the value of EA can be communicated: EA can support the planning of integrations (i.e. via roadmaps), reduce complexity by checking vs. no longer required SBBs and create decision transparency throughout the implementation.
Compared to this a greenfield client will be much less burdened by previous challenges in SAP implementations and software debt, but requires a stronger alignment on what it means to start from scratch. In these instances the opportunitites to standardize and innovate are bigger along the risks to be overly creative in technology decisions, leading to potentially oversized landscapes or landscapes that miss the mark of what the business needs.
How the value of EA can be communicated: By taking the lead in understanding the business strategy and aligning it well with the IT goals EA can provide benefit in both the overall formulation of the implementation goal as well as creating an explicit understanding on both business and IT side of what is needed.
Consideration #2 – Stakeholder analysis =/= emphasis
Understanding your stakeholders is not only a task required to properly go through the preliminary and vision phases of your EA work, but also the foundation for understanding many arguments for and against certain ABBs / SBBs. However securing the buy-in needed from the stakeholders requires more than placing them in a list and ranking their influence.
How the value of EA can be communicated: EA creates the opportunity to find an (often) outside perspective on many facets of business and IT both. As an EA is required to communicate with various stakeholder from different departments they can facilitate an understanding between them and assist in informing them on synergies, as well as help avoid isolated department only solutions to maybe organisation-wide challenges.
Consideration #3 – Deliver key messages
It is quite easy to get lost in the intricacies of our various in- and outputs needed to progress through the phases of EA. As with other areas of IT more often than not time pressure or similar constraints can create a disconnect between the actual work done and the work shown throughout the process. Hence it is vital to regularly communicate deliverables, insights and changes to stakeholder.
How the value of EA can be communicated: Providing a proper communication plan creates the foundation of delivering key messages, and thereby value, to stakeholders. Due to working closely with stakeholders EAs have a strong hold on communicating results with them. Further on the EA can setup / help in setting up KPIs to measure the architecture against, providing the basis for propagating measurable value achieved, necessary findings and changes, to the organisation. Overall a better transparency and a review of successful initiatives can be achieved.
Consideration #4 – Focus on methodology
Using established standards (i.e. TOGAF or yet-to-be established standards like SAP IEAF) shows that the delivery of architecture work in and off itself is transparent in its progress, its in- and outputs, and the artefacts it creates. As in other lines of business and technology standardization allows for efficiency and consistency.
How the value of EA can be communicated: By using standards and standard frameworks the client / organisation has a baseline of security that there is no experimentation or overtly big inefficiencies in the work products themselves. While these are standard frameworks most can (and should) be adapted (read: tailored) towards the specific needs of the context and thereby provide a degree of customization that prevents just following the method to the letter, required or not. Providing not just transparency and planning, but also the capability to measure and monitor throughout a project helps resolve newly occuring changes or situations (not previously planned for) from the central perspective the EA can provide.
Hope you found this post insightful.
EDIT: If you are looking for some further insights I can also recommend this post by Paul from some years ago: Four Tips That Lead Enterprise Architects from Mis… – SAP Community
Br,
Toni