Update your SAP Skills in 5 easy steps

6 11 2015

With the down turn in the economy now is a great time to update your SAP skills.

SAP has a huge breadth of technical and functional content for anyone to be an expert in.

So where does one get started?

Here’s just one approach I’ve used:

  1. Understand your passion(s).  Make sure you take inventory of your passions (What makes you want to get up and come to work).  This will be the skills you need to rank and focus on. 
  2. Review and study the SAP Product/Business road maps and various online presentations.  Take time to understand where SAP is headed strategically.  This in combination with your passions will help you identify your studies. SAP Roadmaps can be found at http://service.sap.com/saproadmaps
  3. Realign your passions to the SAP direction.  It is important to align your passions with SAP’s direction if that is your desire – this may mean re-learning new SAP technology platforms. For instance, if your passion lies in HCM you might consider updating your skills in SuccessFactors instead of focusing on SAP ERP HCM since SAP’s priority is towards SAP Success Factors. 
  4. Develop your Training Strategy.  Now that you have an understanding of SAP’s direction and your passions, prioritize the products & platforms you need to better understand.  You also may want to estimate and time box how much you are willing to spend on each.
  5. Use the following resources to develop your SAP Skills:
  • Open Online Courses Delivered by SAPOpenSAP is SAP’s innovative learning platform and a thought leader for Enterprise MOOCs (Massive Open Online Courses).
  • HANA Cloud Training – Get access to free online video tutorials for developers, administrators and consultants. Topics range from practical how-to instructions to more conceptual projects to help build out new applications.
  • Various Cloud IDES System ProvidersGet access to a HANA system in a day for around free – $25+/Month (i.e. WFTCloud.com, hcp.sap.com,…).  This system you can use in conjunction with OpenSAP or other various training tutorials.
  • Help.sap.comAccess SAP Master Guides (SAP MarketPlace Account required) to understand various deployment options and scenarios.
  • Solution Explorer – A complete list of SAP solutions, associated value maps and solution details
  • Innovation DiscoveryRequires service marketplace account.  A fast and easy way to find new SAP innovations and functionality by product release.
  • Improvement Provider – Improvement Finder helps you discover various improvements delivered through SAP’s Customer Connection program.  Improvements that most customers desire.
  • UX Explorer – SAP User Experience Explorer provides information about a subset of all SAP technologies, tools, applications and solutions related to user experience.
  • SAP Community Networkallows one to stay up to date with the latest SAP news, projects and features. This includes having access to a social network of SAP professionals and experts.  Provides high level to very detail information for various audiences.
  • Americas SAP User Group (Account Required) – ASUG is the world’s largest independent SAP users’ group.  Through national conferences, collaborative initiatives, online gatherings, and user-driven educational tools and material, ASUG provides organizations of all sizes with resources and solutions critical to enhancing business efficiency.

There are many other resources, however that depends on you role. passions, and level of information required.

If you have any inquiries, don’t hesitate to reach out.

Darin Paton
Certified SAP Enterprise Architect
Cornerstone Consulting Inc.
E: dpaton@cornerstone-ea.com
W: www.cornerstone-ea.com



#016 Make your Technology Assessment More Objective and Structured

28 11 2012

Over the years as an enterprise and solution architect I have been involved in many projects to find the best technology for a business problem.  In most instances I have found that either IT or the business already have a solution in mind. However, typically after gathering the functional and non-functional requirements, the solution is not the right fit for various reasons. This is why having the  technology assessment processes and templates in your architecture toolkit are so important.

So I thought this would be a great article to share with other fellow architects out there that are requiring a process to assess and evaluate solutions for the business. Here are my 16 steps which you can trim down depending on the circumstances:

      1. Kick off the assessment. If you’re thrown into a project where an assessment is required then respectfully provide a justification to do one.  The number one justification I like to use is it protects the stakeholders and company from selecting the wrong or rigid solution due to 1) Lack of requirements or 2)Lack of Governance; 3) Stakeholder involvement.  It’s all about doing what is right which most people embrace.
      2. Business Strategy and Roadmap Workshop.  I like to kick off the assessment with a strategic planning session where the business gives a perspective of why the solution is required and how it fits into the long term strategy.  Most times the business can articulate this very clearly, however most of the time they are only trying to solve an isolated issue.  You will need to discern whether a strategic workshop is appropriate based on the culture, it can however, facilitate the bigger picture.
      3. Project Priorities Workshop.  Focus on solving the business problem and keep the workshop on track.  The business always has a lot of nice to haves, so it is your job to focus on the project goal.  I like to use the following quadrant diagram to find out where each priority lands.
      4. Functional & Non-Functional Requirements. Have some good Business Analysts help hammer out the requirements and coordinate the review.  Of course Architecture standards helps with the non-functional requirements – and make sure the architects and specialists are engaged.
      5. High level process inventory and documentation (AS-IS/TO-BE).  Keep the processes high level as there will be time during the detailed blueprinting to refine these processes.
      6. Define the Logical Application and Information Architecture. Develop the required architecture views based on the stakeholders.  A modeling tool is always good to have, since it can really streamlines your work.   I use Avolution Abacus, although I have used Aris, Aris Express, and of course Visio, but I find Abacus for its intuitiveness and flexibility.
      7. Choose vendors for product evaluation.  If there are no internal solutions you will need to find vendors and sometimes you can use research companies like Forrester, Gartner,… other times you will need to search the net, ask the business and technical specialists, and reach out to possible partners.   Try to find vendors that are familiar to the industry you’re in and obtain the magic quadrant and hype cycle documentation if available.
      8. Produce the vendor questionnaire.   Develop a questionnaire based on the logical architecture and requirements for the vendors but keep it simple.  Limit it to around 30-40 questions in total.
      9. Schedule vendors for demonstrations.  Make sure to have a vendor demonstration script based on your needs otherwise demos will get off track.  In some cases it requires putting together data sets to support the demonstration.
      10. Send out and review the vendor questionnaire.  Before you send out the questionnaire make sure to contact Supply Chain to embrace any internal procurement standards.  Have a deadline and single contact for questions.  Review the responses collaboratively and score.
      11. Conduct vendor demonstrations and validate key functionality. This allows your team  to ask questions not in the questionnaire.  Make sure key technical and functional decision makers are present to ask their important requirements. Also, get the stakeholder to score the demonstrations and take notes.
      12. Score vendor questionnaires & demonstrations.  Score collaboratively through a post-demo meeting and document the great feedback.  If scoring is close meet with stakeholders 1:1 for another feedback loop.  You may also have to put a weighting on important requirements.  For example, a question could be scored from 1-4, however if t has a weighting of 3, then the final scores could range from 3 to 12.
      13. Shortlist/select the vendor for a Proof-of-Concept.  You will typically find the governance team will have a favorite vendor which the scoring should align to.  I typically find the result is pretty cut and dry.
      14. Execute the Proof of Concept (PoC).  Keep it simple to begin with, doing just enough to do a PoC competently.  Make sure that Legal gives you recommendations of what is required of the vendor.  i.e. Confidentiality agreements, liability insurance.   Have defined decision gates  at certain points to ensure the technology is still a good fit.
      15. Complete the Technology Assessment & To-Be Architecture documentation.  During the PoC prepare a decision document of the physical architecture options and a recommendation.  Complete the technology assessment as much as possible until a final governed decision is made.
      16. Prepare the business case and implementation plan.  When the decision is final work with the PM to help put together the business case and implementation plans.  You can find my ROI template in the BOX Flash Widget on the right frame.

Multiple times in my career I have either had to execute a technology assessment or coach architects on how to perform the assessment to help the business solve their issues.  The process and templates have evolved over time working with various organizations and peers in the industry.  The best tip I can give you is get the stakeholders in a room regularly to review and give feedback on the process.

What sort of Technology Assessment Processes do you use?

Managing Project Architectural Challenges

7 01 2012

The original title was “Managing Projects Implementing Crap”… but I thought that was a little too harsh. It’s reality and each organization will need to make difficult decisions as part of each implementation.…

Occasionally significant architectural principles/standards of an EA Strategic
implementation, or related project, are sacrificed, even when architectural governance
is in place. Why? In this series of blogs we will look at:

  1. Some of the typical reasons and principles that are broken;
  2. Try to understand why the decisions are made; and
  3. How to manage and respond to the architectural issues that arise.

Some of the typical reasons and architecture principles that are violated

Having been part of many large enterprise projects since the early nineties I find that many
businesses executing on their strategy through IT related programs or projects end up making decisions that compromise key architectural principles. It begins during the project preparation phase
when an estimate is delivered. The typical large project estimating process follows a scheme similar to:

  • 10 days for a very complex (i.e. Process, Report, InterfaceConfiguration, Enhancement…);
  • 7 days for complex;
  • 5 days for medium complexity; and
  • 3 days for simple.

However, more often than not, the preparation and estimate seldom reflects the reality.  This ends up forcing the implementation teams, to make decisions that do not appropriately favour the architectural principles or standards.

The three significant architectural principles I typically see violated across all architectural domains (process, application, data, and technology) are:

  1. Lack of reusability – The solution will meet the immediate business requirement and scope of the project, however, when the solution needs to be extended it requires significant rework, if not a complete re-implementation.
  2. Solution is not operationally efficient – The requirement is implemented with many manual processes to support the end solution.
  3. Lack of Sponsorship and/or Requirements – I can’t tell you how many “Build and they will come” and “Technology Drives Change” projects I have been part of and the majority of these implementations rarely
    end up being successful. The technology ends up getting implemented, but the solution does not meet the business need and the business does not use the solution.

Now this does not mean there won’t be exceptions and a process in place to manage those architecture exceptions. I’m talking about architecture design/principles that are intentionally or unintentionally violated.

In one case, having presented the architectural documentation to a small group of enterprise
and solution architects they quickly realized there was no business engagement and all principles of a single architectural domain were violated.  This caused the project to step back and re-strategize its approach.

In another example, the developers for a solution were pressured to deliver on time rather than adhering to architectural reference models and design.  A quick internal project governance meeting was held to review the options and benefits to make a decision that was best suited to the company and stakeholders versus the project.  The developers were given more time to implement
the solution the correct way.

There are examples, when suitable options and recommendations are presented to the Project Governance
Council.  However, a decision is made to not embrace the recommendations made for various reasons. Sometimes the decision does not even make it to the governance council. In the next blog we will discuss why these issues arise and how to appropriately manage and respond as an enterprise/solution architect.

What are your experiences?

Streamline TOGAF with Enterprise Modeling

3 12 2011

Ever try to find the most current architecture model or documentation in your organization?

In the majority of organizations I’ve been in it has always been a challenge.

My modeling experience:

      1. 1997-1998 Modeled in Oracle Designer 2000 which at that time had pretty good modeling capabilities. However, was not a priority to the business to sponsor and lost traction.


      2. 1998-2007 Visio was the accepted tool of choice, probably since the tool is very intuitive, file based, and seemed easy to search… 🙂


    3. 2007-current Enterprise modeling tools have been my choice of tools lately, with the exception of some engagements where Visio still is.

Some Key Enterprise Modeling Functionality

      1. Allows you to centrally store and version your models.


      2. Each object (i.e. process, function, system, interface, data, infrastructure) has characteristics attached to further describe the object.


      3. The objects store metadata of what they are and do.


      4. Well defined drawings (views in TOGAF) define relationships between the different objects which allow for the generation of TOGAF core matrices and catalogues


      5. All objects are reusable including all the characteristics, descriptions/documentation, and relationships. (i.e. If you copy an object for your drawing, all other relationships are retained)


    6. For each model, documentation can be automatically produced defining all the components of the drawing

For more information on EA modeling tools check out this site.

What is the Value Proposition?

    1. Promotes an “Single Source of Truth” or the authoritative source for models and object definitions resulting in efficiencies in:

  • Streamlining business processes
  • Time saved searching for most current documentation

Value: Consultants $$$$, architects $$$, project staff $$, support staff $

    2. Accelerates modeling and documentation for projects since:

  • Models are centrally stored in the authoritative source.
  • Accelerates models as core matrix and catalogue deliverables are automatically generated.
  • Documentation can be partially automated as each object has the textual documentation associated to itself.

Value: Consultants $$$$, architects $$$, project staff $$, support staff $

    3. Allows for impact analysis to reduce risk in organization changes.

Value: Risk $$$$+


      1. Getting buy in from the executive to embrace the opportunity


      2. Keeping the information up to date and populating the enterprise modeling repository


      3. Managing change to deliver the information to the business and training


    4. Governance service to manage the submission of new and updated models

Kicking Off or Evolving Your Enterprise Architecture (EA) practice.

23 08 2011


TOGAF 8 EA Certification

I’ve been holding off on answering this question (How do I start an EA Practice?) for a while which has been posed from a few of my contacts. So I thought I would share a few of my experiences…over the past 14 years of being involved in architecture teams.

Top 3 realities:

  1. Architecture teams come and go depending on the Corporate/IT leadership…So hang on 🙂
  2. It typically takes years to mature an internal holistic EA practice
  3. With a little value, leadership will give you more responsibility (and rope)

Starting an EA Practice is a very difficult question to answer and is different for each organization. The consulting answer is “It depends”… There is no silver bullet straight out of the gate. There are only guidelines to follow and generally takes many years to mature an EA practice. With this in mind, focus on the priorities and value propositions from your sponsors’ and leaderships’ perspective. This will aid in keeping the EA momentum going so that you can continuously grow the practice.

Here are some steps to consider while strategizing an EA practice?

  1. Self Education: Understand what EA is…Self-educate, take a course, and/or recruit a reputable consultant.
  2. Be Prepared: Define your vision of EA which you can incorporate to future strategies, plans & executions.
  3. Probe for value: Ask questions and probe leaders of current pain points in your organization (IT/Business)
  4. Evaluate the Situation: Based on feedback, develop a business proposition, and communication for EA.
  5. Find and educate the Sponsor: Educate the need for EA to a potential sponsor (C-Level, VP, Director,…)
  6. Approval: Get approval to proceed otherwise go to step #1,2,3, or 4. If you don’t have leaderships blessing or a sponsor…Stop & re-evaluate.
  7. Evaluate current EA: Objectively evaluate the current state of your EA practice focusing on pain points
  8. EA Role: Clarify your role as Chief Enterprise Architect with your sponsor & leadership
  9. EA Leadership Team: Assemble an EA Governance Leadership Team (GLT) and its role
  10. Strategize EA: Collaboratively develop a 3-5 year strategy with the EA GLT and other stakeholders
  11. Prioritize: Prioritize the strategy into yearly executable portions
  12. EA Working Team: Assemble an EA Working Committee and its role (Domain Specialists)
  13. Plan EA: Develop an EA Project plan and schedule for the first executable portion
    1. Include determining a suitable framework and standards to get started
    2. Review the Plan: Review the EA Plan with the EA GLT
    3. Execute & deliver on your promises
    4. Go to Step #5

These are extremely high level steps to start an EA practice and not necessarily true for your organization, however, assuming you have prioritized value-added scope your delivery will gain the momentum required to keep architecture a value add team in your organization.


Got the Patience to Run the EA Race?

8 07 2011

This is a testimony of a good friend who is a data architect. We were both invited to speak at the SAP Sapphire conference in 2011. The subject we were speaking on was the importance of data governance and EIM. As we began to pull our slide deck together he mentioned, “I have been trying to get data governance going since 2003 and I am finally getting some traction with the business and executive. That’s 8 years!”

As I listened to him I nodded and smiled. I got up and drew a diagram on the whiteboard and replied “Is this what you mean? Because this is something you drew on the whiteboard in 1998. That was 13 years ago! That makes you a really old data architect.”

This is an example of the patience he showed over 13 years. How did he do this?

As I watched him over those 13 plus years there was something special about him we can all learn from.
1. The passion and love of your work
2. Never give up. Stand firm if it’s the right thing to do.
3. Always be intentional to improve and promote your idea whenever the opportunity arises.
4. Be objective, don’t worry if you don’t get your way. If the right people can not see the importance and value in the message then the business aren’t ready anyway.

His patience has finally paid off as key executives are bought into the idea and are undertaking a Business Transformation program in which data governance and data management are key components.

Endurance and patience is always important if you want to run the EA race.

The Software Licensing Challenge

23 03 2011

As enterprise architects we are always drawn into licensing agreements in some capacity. Having been involved in many licensing agreements there are some key things to keep in mind.

1. When re-licensing get a list of what you own, type of and capacity license, and how new products map to any new product licensing. This is a simple gap analysis to understand what you have and what is being proposed. Re-branding products can make this complex.
2. Wait to sign agreements until the end of a quarter or better yet, the year. Of course depending on the economy.
3. If you really need the software, try to get services included with the software prior to signing the agreement. Identify the competency level of the consultants; no change in support % rates; support incl. in first couple years,…
4. Be sure to do a proper assessment to choose the right SW product.

Need guidance in negotiating licensing?

%d bloggers like this: