Skip to Content

The Governance Architect


At one stage I was exploring moving the Detroubulator into the ABAP stack and provided a design to do this.  The following link shows you how I approached that which apart from screen design, covers most of the steps discussed in this blog to a degree.

h3. Final Sell Point 

Firstly, doing a high-level design like above is great for:

  • Being able to reuse and enhance your existing code base if it’s all within the same UML repository.
  • It saves you time for any non-trivial development.

How often have you come across genius introverted developers that can do anything but when you look at how they did it; you realise that very few people in the world will understand the concepts used and basically, they’ve just developed an unsupportable application.

So secondly, if you are in a governed world; it’s important to understand what the GA is looking to approve.  The description that has worked best for me is that the design needs to be written in such a way that you are happy to give this to another developer to develop and know that for the most part; the design will deliver the required solution (the developer still needs to design parts of the solution, but the design decisions should be more trivial and not require GA approval).  

For me, from a GA perspective, the above approach gives me a design that I can easily understand and approve.  Alternatively, from a developer perspective, I use this approach personally and can really say that it’s incredible how much better the solutions are when you approach it this way.

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

  1. Matt Harding Post author
    A friend mentioned that I would be asked why I would reject this design, and my short answer would have to be:
    This is a pretty common requirement in most organisations…Request something, track the request, approve it and action it.  Hence, I would have been looking for the developer to leverage a more factory approach to this and leverage a common workflow (with factory class calculated approvers) as potentially the database for this action (depending on requirements).  My friend actually had implemented exactly this and this was one of the coolest designed apps in a previous organisation we both worked in so he knew it was a leading question 🙂

    Anyway, just in case you wanted to know.

    Cheers,
    Matt

    (0) 
  2. Simon Kemp
    Thanks for the blog Matt. You mention that one of the important things is to make sure you try to reuse functionality and objects that are already available in the system (i.e. not re-inventing the wheel). Do you have any tips on where to start looking?

    I really like your pragmatic approach to design. I am a big believer in not just documenting for the sake of it since when documents become longer than just a few pages they tend to just gather dust!

    (0) 
    1. Matt Harding Post author
      Hi Simon,

      Great question which if I assume you are referring to SAP objects to leverage; there hasn’t been a great way of doing this that I’ve come across. I believe there are some improvements in the later releases that highlight which classes you can officially use (like BAPIs) but not sure what release this starts in (or whether it is leveraged very much).  There’s the obvious search for CL_* to find classes, you can run through the relevant areas in debug mode identifying the most appropriate Packages and look in se80 for suitable classes within those Packages; and then there’s of course BAPIs to look at wrapping your own class around (which is probably one of the few official ways to do this which is also rarely used in reality).  For reference, exploring various packages has worked best for me in the past.
      It’s important to note that use of internal classes does involve risk similar to using internal functions.  That said, I don’t believe it should put you off using it when it’s appropriate and a fairly mature class.

      If you are referring to existing code that has been developed; then hopefully your client has naming standards and you can do a ZCL_* and ZIF_* search and pull up most of the existing classes.  Even more hopefully there is an enterprise modelling tool and you can simply leverage the objects directly…This is highly unlikely in my experience unless you are building SAP modules.

      Note – In terms of documentation gathering dust, it will be interesting to play with 7.02 with the automatic generation of sequence models.  I wonder whether you’ll be able to import this into your own modelling tool or whether this is informational only (I believe its informational only).

      Cheers,
      Matt

      (0) 
  3. Edward Pelyavskyy
    Matt,

    Thanks for the blog. It gives me hope that somebody out there is using the right tools and most of all understands why he is using those tools. 😉

    Your comment “…I still find it extremely challenging to introduce OO to non-OO skilled resources…” resonates with me the most.

    Do you have any “unusual” hints on introducing OO to ABAP-ers? Or the usual training, explaining, starting with a simple not mission critical project works?

    Sorry I didn’t have any questions about the technical aspects of your blog 😉

    Regards,
    Edward

    (0) 
    1. Matt Harding Post author
      Thanks Edward.  No problems not having a technical question about the blog as it’s just good to see responses that tend to agree with these approaches.
      In terms of the OO question…No easy answer although from an ABAP perspective I would point you at a set of 5 tutorials within the ABAP Freakshows at Enterprise Geeks by Thomas Jung that I would tend to sit anyone new to the world of objects through…
      http://enterprisegeeks.com/blog/2009/07/01/abap-freak-show-%E2%80%93-july-1st-%E2%80%93-abap-oo-tutorial-part-1/
      You probably know about that already, but it’s a good start.
      Cheers,
      Matt
      (0) 
  4. Alisdair Templeton
    Hi Matt.

    It’s good to see UML getting a plug, and as an Architect who seems to be continually reading documents, UML makes a lot of difference in getting the Solution across.

    Personally, I would get a Domain Model in place first, and also translate some of the important Use Cases into System Sequence Diagrams before I got my developers building up their Object Models from their Sequence Diagrams. The problem with building up your Object Model this way is that it’s a Bottom Up approach, and you can easily lose sight of the big picture – hence I like to mitigate with a Domain Model. We’re not talking a complete model here – that’s almost impossible – were talking the main Objects that are required for the current Iteration – it’s an iterative artefact like many others in this approach.

    The advantage of seeing a Domain Model early is that it demonstrates to the Architect that the developer(s) have understood and decomposed the Problem Domain correctly. There is some indication of what the Entities are, how they relate, and what their responsibilities are. There identification also means that when they are translated into an Object Model there is a better chance of a lower Representational Gap between Design and Implementation.

    Building Sequence Diagrams at this stage will then help validate those relationships and responsibilities. This then allows us to apply all the good OO Governance stuff like GRASP and SOLID.

    I guess it’s a Chicken and Egg thing…

    (0) 
    1. Matt Harding Post author
      Hi Al,

      The approach I took is a minimalist approach to get some people over the line in terms of using UML.  The way you describe designing a solution sounds like the approach you should take if you were even more mature (or possibly less mature and being mentored).  It definitely sounds like a practical approach to me that I would take on larger scale problems where I don’t know the problem space so well.
      That said, I used the above approach with a fairly large custom external facing Portal development and it was extremely advantageous for me but I also acted as the business process expert in this scenario so hence could avoid additional steps.
      Now knowing your background in software development, something that is obvious when comparing your knowledge with what I see in the pure SAP development space is that the software industry practices leveraged by most SAP consultants are a step or two behind non-SAP software development practices.  For example, I don’t know what GRASP (General Responsibility Assignment Software Pattern) and SOLID (Single responsibility principle, Open/closed principle, Liskov substitution principle, Interface segregation principle, Dependency inversion principle) are without resorting to Wikipedia and even then I’ve got a lot of reading to do to catch up (seriously – Liskov substitution principle!!!).  It would be great to get your view in a blog about translating all the JAVA best practices into the ABAP world using layman terms since you keep up to speed with both. That’s my challenge to you (feel free to reply with “Challenge Accepted”)…

      Cheers,
      Matt

      (0) 

Leave a Reply