Please Note

Within this blog, I’ll mainly use solution design and development as the main focus area, however with some tweaking of examples, this could apply to any part of supporting an SAP solution such as process design, functional configuration, basis, infrastructure, etc.

Is Solution Governance Important?

How many of you out there love to add comments and version history to all your code?

What about following a companies naming standards when you’ve been raised on a different standard?

Most of you will most likely want to do the right thing on all developments even if it is a little harder, but how many have been on a project under the pump (with unrealistic Project Managers) and you’ve made a decision to do a short cut temporarily and say - we’ll come back to that later - fully knowing that it is very unlikely you’ll be back (assuming your shortcut doesn’t introduce a problem later in production or during an upgrade).

Well this is just one point where solution governance, in my opinion, comes in.  It’s human nature to take short cuts, either out of necessity due to timelines, or otherwise.  But while it’s potentially acceptable given the circumstances; for any “temporary” shortcut, the solution will accumulate Technical Debt* that in some way or another, you will need to pay off one day.  Typically, the project (and it’s associated funding) walks away leaving the operational budget to pay it off and that is not likely to occur.

Just by having someone who “cares” enough to uphold strategies, principles, policies, guidelines, naming standards, ensure that peer reviews occur and are at a sufficient standard, etc; can make a huge impact to the ongoing quality of the solution.  So even if a short cut is required due to timelines; governance doesn’t have to change this short cut, but it can get the project (or business) to ensure it refactors the development before it drops into operations (or at least budgeted in a future project).

Of course there are many other good reasons for Governance, like providing a clear and consistent vision for all new solutions so that investment is made strategically, ensuring no compliance issues are raised, identifying the true position of a project (compared with the Project Status report), etc.

* Thanks to Al Templeton for introducing me to this term. Love this analogy.

Is Speed or Agility important?

With governance now in place, you now have to deal with the perception that all projects appear to cost more due to the extra effort of governance that projects need to commit to. In addition, the business may get frustrated as governance can bottleneck your projects if processes are not efficient or projects are not engaging correctly (either accidentally, or deliberately but that’s a whole new blog to cover that issue off).  Then there's times where the business is not exactly sure what will work, hence the requirements need more agility than you can typically govern.

You can sell governance easily when you save the day or avert a disaster, but when things go smoothly; it’s almost impossible to measure the investment of paying the Technical Debt up front against the accumulating cost of the Technical Debt plus interest that is not paid off (as I said - I love this analogy).

This is probably not a problem for your big projects - everyone knows that these are important to govern well, but smaller projects typically want to be agile, or deliver quickly at lower cost. In these scenarios, full strength Governance introduces a delay and comes at a cost which may be a delay or cost that is too high for your business (and I’m sure many knows what typically happens next).

Is innovation important?

Fo some industries this may not be an issue (questionable though).  At least in the mining, utilities and retail industries I believe innovation can make a huge impact.  Maybe from process efficiencies through an offline mobility solution, or through better engagement with customers with customer analytics (check out Smart Meter Analytics on HANA as a very cool piece of tech).  While innovation can be a big project, I typically think introduction of innovation best starts on a small scale.  This avoids too much bleeding of your bleeding edge solution and the ability to remain agile (even stopping the project early if necessary as an example).

The great thing about innovation within a business, is the business typically loves this stuff almost as much as the lucky developers involved.

Capital Expenditure or Operating Expenditure?

This is another blog waiting to be written as it’s a constant battle to get the right amount of operational budget to support governance, and then there’s the battle around architectural deliverables being treated as a capital and not an operational expense.  i.e. The CFO wants to lower operating expenditure but governance teams don’t want to be treated like a tax on projects but a “free” service including in the operating budget.  So the trick is how to get sufficient budget to support good comprehensive governance (eg. It’s not one FTE we’re talking about here).

What’s the idea?

Let’s look at just a selection of the mandatory experience or skills for each area (generically thinking around SAP Solution Design):

Solution Governance:

• Good knowledge of the SAP solution and roadmap in order to review SAP Solutions for company XYZ
• Good knowledge of the company XYZ’s vision, strategies, processes, etcUnderstands best practices in SAP
• Ability to quickly review solutions to ensure compliance with all company principles, policies, strategies, compliance, etc
• Owner of naming and design guidelines for SAP Solutions

Speed/Agility:

• Ability to quickly take business requirements to identify the candidate SAP solution, proposing new SAP solutions as required
• Good knowledge of the company XYZ’s vision, strategies, processes, etc
• Ability to develop solutions that comply with all company principles, policies, strategies, compliance, etc

Innovation:

• Understanding and positioning of SAP’s roadmaps in order to identify where innovative solutions may address business requirements
• Ability to develop solutions that comply with all company principles, policies, strategies, compliance, etc
• Define naming and design guidelines for new SAP Solutions

I could think this out further (considering transition to support activities as an example), but in short, there’s a lot of cross-over of these roles, and if you look at this in a cycle; being able to Govern the solution, means you can provide, when required, speedy strategically aligned solutions and if required, innovative solutions, which if new technologies are involved, need to be governed.  It’s a bit of a stretch, but this then allows me to throw an obligatory diagram into this blog showing this cycle (with Innovation where required).

Figure 1 - Obligatory picture or model in blog - Describing the SIG model

So in short, the idea is to build a governance team which also has the ability to release individuals or groups of individuals for an annual average of 50% of their time to take control of any urgent or innovative projects and develop them in an appropriate way and an expedited manner while still being governed but also establishing any principles, strategies, etc; for new technologies/approaches as required.

Further to this, we’re now talking about a solution governance team which does a good percentage of capital work; hence win-win for both the Architecture Governance Manager in terms of head count and capabilities, and the CFO in terms of lower operating cost (not to mention lower Capital expenditure)!

An Added Bonus

I’ve been a governance architect myself, and the one thing that worries you most is the fact you can start to lose your edge if you don’t actually develop a production solution for yourself occasionally, especially on new solutions.  And when you’ve done this, apart from being a perk just to take part in innovative solutions, it also adds credibility to project teams when you do actually know what you are talking about.

Also, when so often you are tasked to correct the direction of projects, it's great to be enabling the business directly which I believe is also a good way to retain these people, not to mention investing in your own people and not contractors.

The Catches

Solution governance is providing an independent review or at least transparency around a solution, hence throwing an entire team into doing a project means you no longer have anyone who can govern the project.  By keeping all the Governing team at least 20% operating expenditure during assignments this should not be a problem.  Heck, why not throw in a Friday Innovation afternoon while you're at it like SAP does!

Lastly, urgent and innovative projects should not be super frequent events.  This is not a “bypass all planning and release management” approach to SAP Solution Governance.

TechEd 2011 DemoJam – A fun event but...

I really enjoyed this year's DemoJam though it was an enjoyment with a niggling concern that the show had lost the focus and soul of DemoJam. I also strangely felt I had been marketed to rather than seen genuine competition between diverse DemoJammers.  

There’s no doubt with the new format that Marek and the rest of the SAP Research team involved in Brisbane (Aussie, Aussie, Aussie, oi, oi ,oi) deserved to win as they showed us something really innovative and awesome but has the point of DemoJam changed?

So what’s wrong?

Okay – I believe DemoJam is about innovation in the SAP Enterprise space, and all the participants definitely were innovating in their space (I was really impressed with all of them); but in my opinion it was more a show of SAP products/features (new or upcoming) than a competition.  Even the host would give biased information about each presentation (albeit in an entertaining way) but this added to the fact that it was more of a sell than a true competition.  There were a couple of entries that were more traditional entries but the playing field was not really fair in my opinion (though one got really close).

In previous years, Al Templeton and myself would say – “We need to enter this” – “We can win this” - then last year we did and won - but with this year’s entries – there’s no way we would have even tried. For us, it wasn't months of development, but there was definitely some significant personaltime invested by us into DemoJam.  And it wasn’t just us – most entries I believe were all in the same boat (shout out to John Astill).

See to me, DemoJam is best when it is a truly geeky event where developers/innovators get to show off something cool and practical they’ve done in their own time for the enterprise.  It’s not SAP professionals showing something they’ve being doing as part of their day job for the last 6-12 months or longer.

So to add to my angst, when we won, we had no qualms in encouraging others to compete in the 2011 competition but looking back at the change in format, I’m worried about our advice?  

Is DemoJam now a Marketing Event?

I can't help think that as soon as you open up DemoJam to presenting your day job - it becomes simply an exercise in SAP marketing and who's got the best use-case/technology.  If this was the scope, then I’m surprised porting ABAP development into Eclipse wasn’t includes as that would be another excellent DemoJam idea (maybe it is at another venue - if so - good luck!).

HANA – Not sure why this word appears here, it appears to be mentioned everywhere at the moment whether it is needed or not.

Prosed New (or is it Old) Rules

So I’m nearing the end of this scattered rant; but how about some rules for next year’s DemoJam:

• Demo must be leveraging/working with SAP products in an innovative way with a real business use case
• Demo must be put together in your own time and not part of your day job – Sure – if you have a 20% Google innovation policy – that’s probably okay but it shouldn’t be something you have a KPI to deliver!

And if the rules reflect this; I’ll pledge to enter next year’s event (hopefully Al will still join me) and challenge other’s to do so!

Some last Comments

Inclusion of Innojam Winner

While I’m still waiting for the SAP Mentors to release the “Do I Know you?” app; the inclusion of the InnoJam entry was a good thing.  If the above rules are put in place, then not only should the innojam be presented on stage, but they should be part of the competition and voted upon.

Finally a Shout Out to The Winning Team

Knowing where SAP Research came from with the demo – they definitely put in some effort to get ready for DemoJam.  Things were looking awesome at the beginning of the year when we first saw this at Mastering Technologies under the very cool but trademarkable name “Holodeck”; but the use-cases were limited at that point.  I still definitely have high hopes for this to be productionised ASAP – especially with the BPMN use-cases.  Anyway, kudos to the team and look forward to seeing more impressive stuff out of the research labs at SAP.

Introduction

First up, I should highlight that this was my first business focussed conference I've gone to.  I've attended SAP TechEd numerous times and followed the online presence of Sapphire/ASUG last year; but coming to a conference where everyone is walking around in suits and "deep dive" refers more to looking into screen shots of future functionality (with no code) was definitely different for me so this blog will be possibly bringing more a different perspective than others who attended this event.  i.e. I found the industry content the most fascinating rather than the product announcements (which are also important of course but more my day role).

Secondly, I intended to write this up closer to the event but you know how it is with work and life sometimes.  Oh well, at least I published it before Sapphire Now/ASUG…

So I'll cover the overall trip experience (for historic purposes only so feel free to skip to the content section), then provide you an exec summary of the content and key messages/questions. Finally I'll end with my thoughts on whether we are at the point of a revolution in the Energy Industry.

Welcome to Mannheim, Germany

Living in Tasmania, Australia; there are quite a few hops to get to Mannheim and the whole trip is over 24 hours from door to door.  That said, flights were good, I slept the necessary amount to still be conscious and once I stepped off the impressively fast but smooth ICE train from Frankfurt Airport to Mannheim, I was pumped to see what Mannheim and the surroundings had to offer.

The weather was superb and my first trek was to view the parks and various streets of Mannheim.  I won't go into detail, but once I'd seen the parks and the old Uni; I discovered that on a Sunday...Mannheim is a pretty quiet place - so after some advice from fellow Mentor Matthias Steiner - I took off to Heidelberg to walk up to the castle.

I stepped off the train not knowing where I was exactly but after wandering around lost for 30 minutes, I found a landmark I knew and set off towards the Castle (for reference, I could not see the castle from the Train station so don't hassle me). As I said, the day was superb so I shouldn't have been surprised to see nearly every man and woman, their family and their dog was out that day.  For me, that was great as it just added to the atmosphere.  To cut a long story short; I thoroughly recommend the walk.

After finding the train station again (it was almost where I thought), I headed back home and discovered after some dinner that bed was a great idea.

Future Energy Centre (FEC) 

The FEC is an SAP Research lab located in Karlsruhe, Germany which is dedicated to energy research. Apart from a number of very cluey people, it includes a demo/prototype area to highlight some of the research they are doing. As part of the conference, the FEC was celebrating their grand opening that very week.  

Although opening the next day, SAP were generous enough to realise that visitors from utilities from Asia Pacific don't show up every day, and allowed a small number of Asia Pacific people including myself a sneak preview.

Now I have to admit I was looking forward to this visit.  Having recently seen some of the work going down in Brisbane SAP Research at Mastering Technologies in Sydney and being suitably impressed, I wanted to see what SAP were doing in the field of Utilities.

I don't want to give the whole story away for future visitors, but some of the projects they are investigating included:

• Electric Mobility (which by the way, the utility industry is not referring to iPhones/Androids when they say this but Electric Vehicles and the infrastructure that goes with that), 
• Energy storage solutions, 
• Efficiency programs,
• and of course smart grids which included demand/response (yes - like mobility above, Utilities have ignored common IT terminology like DR and used it for their own purposes). 

This YouTube video promotes it pretty well. 

The only unfortunate thing about the visit was the diversity of the group that attended.  It would have been fascinating to discuss specifics with the research leads at the FEC, but having competing companies and different focuses in companies meant that this was not really possible.  Next time hopefully... 

So after a traditional German "Pub" meal in Heidelberg, which seemed to incorporate extremely large plates of salad, potent Garlic Soup, way too much meat for one person to consume and of course, great beer - it was time for bed to get ready for the conference.

Side Note: Bacon

Now why write about Bacon in the middle of this blog. Well firstly, why wouldn't you; but secondly, the Enterprise Geeks experienced Australian Bacon recently, commenting about the similarities to Ham; and having lived in the US, I know what they are talking about.

So the point of this side note is to set the benchmark for Breakfast Bacon...The Bacon at the Dorint Hotel in Mannheim at breakfast has to be the best bacon I have ever tasted.  But I digress...

Conference Time - Executive Summary

First impressions… Well apart from the fact that a Mentor shirt stood out pretty well amongst all the attendees wearing Suits (note to self - don't bother packing Jeans to Business Conferences), was that this appeared to be a well-run event.  Obviously the scale was not on par with Sapphire or TechEd but that didn't seem to stop the coordinators trying to make this an impressive event.  Keynotes were well thought out with the stand out presenter for me being Joschka Fischer (former German Minister of Foreign Affairs and Former Vice Chancellor). The party night had a novel idea that they should adopt at TechEd and the like - drinks and entertainment till 1am in the morning including gate crashers like fellow mentor Gregor Wolf who just happened to be in Waldorf enabling a mini wolfpack formation for the night.  Party on!

In terms of the content:

• HANA was obviously big with new product names announced (main one for me was Smart Meter Analytics for Utilities - previously known as part of what was called Raptor),
• MDUS integration had a strong focus in discussions (this refers to prebuilt integration with SAP that an increasing number of certified partners have implemented to integrate head-end systems that manage AMI/smart meters in order to simplify AMI/Smart Meter processes,
• The research projects going on at the FEC and other SAP Research labs,
• Lots of great customer presentations from across the globe which included both regulated and deregulated utilities (what British Gas has going on sounds awesome),
• SAP’s Energy Data Management had been undergoing some serious internal benchmark testing of AMI scenarios and been proven to linearly scale (with lots and lots of infrastructure tuning) to 10 million customers (with 15 minute intervals between reads)

There were obviously many analysts or suitable analyst types providing their predictions on where the energy revolution (or evolution) is going.  Some of the key themes behind their arguments included:

• Impact of Carbon Changes (including Government enforced changes)
• Nuclear viability after recent events (in some cases it is still the only viable option today)
• Impact of China
• Future of renewable energy (including future pricing of Solar Panels)
• Impact of Smart Grids
• E-Mobility - Remembering that Electric Cars are one big battery than can be used to power the house in times of peak network load and imagine 20 years from now everyone coming home and charging their cars at the same time (in short, won’t work too well currently).
• Sustainability
• The rate of growth in some (and many would say most) countries (China, India, etc) and how to sustain a reliable grid.
• The price of energy – It will continue to go up, but the prediction is that with AMI, price will become much more variable in the future.
• The role of standards (there are currently so many)

So is it a Revolution?

Well after hearing many industry experts, and seeing the discrepancies in many people’s thoughts, be it from fact or passionate viewpoint – the one piece of information that was clear to me was not, "We are in an Energy Revolution", but "We need to be within an Energy Revolution!"

One problem is there is no standard for a smart grid today (or maybe I should say there are many standards).  Systems are being built ahead of completely understanding where we are going (understandably of course) and the technologies such as Solar Panels, Home Area Networks that communicate with your washing machine/fridge and Smart Meter are expensive until a standard exist.  Plus add government legislations that are getting in the way of anyone making these things standards.  Some countries/states being deregulated mean that retailers cannot easily leverage meter functionality to enable their customers as they do not own or control the meters.  Lots of barriers.

Whether or not Nuclear is an option or not (I won’t weigh in on that argument), China’s growth and hence demand for energy is mind-blowing. And if it’s one country that can make renewable affordable for the rest of us; then possibly their demand will drive enough R&D and standardisation to potential partly solve this for the rest of us (no pressure China).

In terms of customers, although we probably don’t care about having too deep a relationship with our utility; with prices going up, we may start to need to.  At least if customers learn that by just switching out those really inefficient light bulbs with a more expensive up front light bulb – that would be a great start. 

The easiest way to think about lowering your bill is your utility offers you the right Time-of-Use tariff with possibly a demand-response option (for times when grid demand is at its greatest and the utility wants you to consume less please) and you take control of your usage. You may go out and then see the benefit of storage and Solar Panels and start to only consume the cheapest energy price and rely internally during the rest of the periods, potentially selling to your neighbour when you go away on holidays!  Of course, making this incredible complex scenario appear simple for all parties involved will be key (one of the insightful messages that was mentioned at the conference).

And my last point – just because maybe your country/state is not the pumping out energy and carbon like California or China doesn’t mean you can wait to see what everyone else does to improve things.  Investment in R&D and collaborations appears to be still the way forward so that we can start this revolution ASAP.

Oh – And please start making more sexier and affordable Electric Vehicles…

So that’s it

So as I pointed out at the start, this conference not only brought me up to speed with much of the upcoming SAP and partner eco-system solutions coming up; but made me think quite a lot.

And whatever the answer to the evolution/revolution question, I’m definitely excited to be in the Utility industry right now.

The Big Picture

Back in the late 90's, I used to work for Fairlight (the company who introduced sampling to the music industry that gave us those classic 80's sounds behind Peter Gabriel, Stevie Wonder, Mike Oldfield, Duran Duran and many others). It was my first job, and I was privileged to work with some great minds that set me up pretty well to tackle anything that work life threw at me (but I digress).

Although it was an office R&D job, on one occasion I was sent to Hollywood from my Sydney home to diagnose a significant Fairlight issue that was happening within a new movie production studio (cool right?).  I was given a couple of days to sort this issue out (you can imagine how much cost that is to a studio to do that), and to give you an idea of what I was up against, it seemed to happen in the mornings, but it wasn't reproducible.

So where am I going with this?  After a few hours I was close to being able to reproduce the problem by repeatedly restarting the system (amongst other things), but I could only reproduce it 1 out of 3 times.  I was stuck effectively so I gave our most senior engineer a call and described how I could almost reproduce this problem.

Now did you know that in a computer, memory persists in RAM for many seconds when you switch it off and unless you initialise memory when you start a system, memory is actually random and not all 0's to begin with?  Well I didn't...but the senior engineer did.

As soon as I combined this knowledge, it was only a few hours to write code to initalise the memory at boot and - hey presto - problem fixed and a day to cruise in LA was all mine!  

The Aging Workforce

Now I'm not the expert on the aging workforce issue within the energy utility industry, but my interpretation of the issue is that for most of the 1900's, the utility business was the place to be as an engineer, with huge investments in infrastructure.  Then as we headed into the 80's and beyond, the infrastructure building slowed considerably, newer more exciting careers were opening up for engineers outside of the Power industry (like SAP).  Now over the next 20-40 years, the infrastructure created a 100 years ago will need to be refreshed and expanded, but those who knew the Power industry back to front are now retiring leaving a "potential" major skills shortage in the future.

So what has this got to do with SAP?

I started to learn SAP when 4.0B was released and as a developer, being in custom development (and not implementations), it really only took a few years to be on top of the possibilities within that environment plus you even had the ability to keep up with the new technologies being introduced.  But from 4.7 onwards; things started to really pick up speed making this tough.

At first we started to see Portals, JAVA, Web Dynpro and other new tools that were still fairly low level; and those caught up in these new technologies were exposed to lots of fun (or pain depending on your view of debugging JAVA dumps, working out how to set-up NWDI, working out what a Business System is vs a Business Service, SLD, garbage collection, etc).  The point being that you still needed to understand the underlying technologies and reasoning fairly well at this point). 

But as the tools grew more mature and were enhanced to make things easier for developers and basis alike; development and basis became more automated.  Best Practice guides and blogs led you down the right path, and things just worked.

Three examples come to mind in terms of recent change in SAP.

1. Web Dynpro for ABAP and the introduction of the code wizard.  Suddenly, instead of needing to understand how to navigate the Web Dynpro class structure; you could just use a visual wizard - and hey - code inserted which seems to do the trick.  "Don't know what it's doing, but it works for me."  Personally, I tend to majorly reorganise and optimse the wizard code; while I can imagine many developers just let it do it's job for them.  Maybe that introduces less bugs, but I'm not going buying into that. 

2. I remember when the dual stack was introduced, and a discussion with what I thought was a senior basis person. We needed to start the ABAP stack but leave the JAVA stack down, and it was at this point that I discovered that the basis person didn't actually know what startsap was capable of.

3. JAVA Stacks offer some great functionality, but unlike ABAP, memory leaks are frequently introduced - sometimes even in the core classes that you didn't write. As far as I'm concerned, too few JAVA administrators and developers know about how JVM's actually work and believe that monitoring of physical memory, CPU and disk is sufficient for system health checks.

In short, when everything works fine - these new approaches are great, but when you go outside the box, suddenly you find you have a major skills shortage unless you've been on the journey with each new technology/application.

 So do we go back to Dialogue and Report Programming and a single ERP stack?

Please don't get me wrong, I think tools like WD4A and add-on functionality are the future in SAP, but we need to make sure we protect our investments by ensuring developers learn the ropes too.  Thorsten Franz wrote a great Model-Driven Development in ABAP about Model-Driven Development (in ABAP but also referencing CE) and this is where the industry is heading in general.  He points out the various opinions about modelling verses coding in terms of efficiency, but key to his comment is that you can "break out" with your own coding when required.  My concern here are the "developers" who don't know how to "break out" and are not even exposed to the requirement to "break out".

 So what can we learn and do differently?

Ground rules for this question first.  The Enterprise Geeks a while back raised some good points about general development capability. Hence, let's just assume when talking about a junior staff member that:

• If they're a developer: they are keen and have already learnt about debuggers, development and test approaches to begin with. 
• If they're a Netweaver Administrator: they know about infrastructure, ITIL processes, UNIX/Windows, etc.  

i.e. We've hammered home the basics to begin with.  You have bigger issues if this is not the case.

Okay, some ideas to what you can do differently:

• Dig deeper into your solutions, and make sure you expose junior staff to real low level problems occasionally (even artificially).  This applies to nearly all areas of SAP, even functional consultants. eg. Has your JAVA developer ever analysed a heap dump or looked at garbage collection logs to understand normal?

• Think about succession planning - don't just talk about it - don't just promote your best developer to project lead and expect them to mentor everyone up while delivering status reports or doing performance reviews - actually make sure you continually train up people.  People with 10 years experience, need 10 years experience.

• Have sandpit systems available for playing - plus give people play time.

• Build a network to engage others in the industry around any solution (not just SCN though that's a good start).

• Always question how the "magic" works.  eg. When I get my hands on my first In Memory Database ERP system - I'll want to know (at least) how it works so I can figure out how to both program sensibly with it, understand the possibilities plus understand how to manage it.

• Watch out for senior 12:00 Flashers - That's obviously a little too harsh (and that link takes you to the Urban Dictionary definition if you were wondering), but I have heard of senior developers who stop junior staff from trying new techniques or approaches (as radical as Object Oriented) as they know the old world so well.  This is a very bad scenario in my mind as you'll end up with a solution no one wants to support in the end (eg. Did you notice that good COBOL programmers are getting harder and harder to find now days). 

• Most importantly - Please understand how much magic is occurring in your solution to understand the risk by reflecting on the solution's business criticality.

Background

Blackberry’s are the Enterprise preferred mobile email and calendar client which are usually forced onto employees; but iPhone and Android devices are the preferred mobile email and calendar client for employees that are forcing these clients into the Enterprises.  The funny thing is that until the iPhone was introduced; Blackberry's were the best option out there because we didn't know better.

Within business process modelling (from a detailed requirements and process design perspective), I believe the best option for business users is to use BPMN.  But the question is: Are we just waiting for the iPhone of Business Process Modelling to come along.

Inspiration for this Blog

A colleague of mine attended Business Analyst World (@ba_world) in Melbourne recently and some presentations from other companies really resonated with her.  

In short, the companies were doing business process modelling leveraging a product that didn't implement BPMN or any other generic standard for that matter but talked to the business users in a specific business modelling language that they could understand.  Oddly enough, the product being leveraged was a product I had seen before, but it had a major drawback for me and that was that it didn't implement an open standard.  Why do I consider this such as big issue?  In short, vendor lock-in; and this is an issue because if you invest in Business Process Modelling of your business; then it is a huge investment that should be maintained indefinitely.

Anyway, this got me to thinking...When it comes to lower level process diagrams, EPC seems to work well, but just seems to be too restrictive and forced to me; BPMN appears to be trying to reach nirvana too quickly with a language for both business process modelling and business process management style Workflow; and finally, businesses and business analysts seem to still love swim lanes in Visio.

So is the future of requirements elicitation near and just not understood well enough by everyone yet, or is it just not being thought about yet?

The Makings of a Good Modelling Tool (An alternate set of requirements)

Firstly, instead of focusing on the standards; the following are what I feel are mandatory for business acceptance of a business modelling tool:

• Usability - Ability to model in front of business users (otherwise we need to work off a whiteboard; then copy into the tool later) - FYI - Mobile Device integration (like iPads) could be an interesting use-case in the future here too...
• Documentation/Training Tool - Process models need to be made available to the whole organisation and easily accessible via a web interface with intuitive usability - preferably integrated with the business applications.
• Displayed in a pretty, well laid out and not boring way - Process modelling isn't everyone's cup of tea; hence it can't be dull to look at as that will lose your audience quickly (just a fact of life).
• Collaboration Platform - Ability for anyone in the business to question existing processes or recommend changes via the web interface used for Documentation/Training.
• Ability to view as-is and to-be changes efficiently – If you’re tool is entrenched in the organisation, change naturally happens; and your tool needs to easily support this.
• Ability to view models similar to the way we document use case definitions – Just like showing a business user 10 pages of documented requirements; showing end to end processes with all variations, exceptions and interactions is just not going to work in getting effective understanding and sign-off from the business.  I believe by just focusing on standard flows, alternate flows, and exception flows similar to old-school use-case documentation; really would allow you to focus the business users and not overwhelm them in workshops.

So About the Standards...

I'm not an expert in Business Process Modelling and I'm also not trying to suggest that I've researched this topic extensively, but I know what will work with business users when I see it (and I haven't yet).  I currently lean mostly towards BPMN style swim lanes or EPC; but I'm not sold on these either.  

Side note: I see BPMN as something very powerful in the execution world with tools like SAP’s BPM combined with the inbuilt business view as a great way for the business to monitor and measure their semi-automated processes; but this blog is focussed on business requirements using business process modelling.

Basically, the purpose of BPMN is to support business and technical stakeholders; hence as a design tool; we’ve probably got it right there.  However, when it comes to requirements and the importance of getting requirements right; let’s drop the technical and focus on the business.

Do we need another standard?  Most likely in my opinion.  The problem is how to write this standard?  We obviously want some link into the BPMN space but this will have to be fairly loosely coupled in my opinion (though a level of reverse engineering in the future would be heading towards nirvana again).  Who is best to write this standard?  Software companies? Probably not though in this day and age there’s little other choice.  

In short, it would be good to see if this is a real need still so I'm interested in your opinion or knowledge here? 

The Business Analyst Role - The most important ingredient regardless of Standards

This is slightly off-topic but I thought was important to add in this context: 

Regardless of tools, standards or methodologies; one key skill I strongly believe is the secret to successful projects is good business analyst skills.  

There's a real art to getting the requirements out of the business without just documenting what they know back to front already.  Often the business will just tell you what they do today, and skim over details that are obvious to them which can hurt implementation projects when you only find out when it's not built in final UAT.

Just as important: because business users are so entrenched in the current processes; sometimes they don't even realise why they do things a certain way.  Typically there are significant efficiencies to be gained if challenged appropriately and while modelling helps significantly; the BA's key in identifying this.

For traditional waterfall projects; Business Analysis is extremely critical as obviously signing off of requirements early means little ongoing involvement between business and the testing cycle.  Within Agile methodologies; developers usually pick up this role; and although maybe not as good as a dedicated business analyst, the shorter iterations and direct business engagement helps significantly as developers are unlikely to misinterpret the requirements; and even if they do; it's picked up quickly.

In short, a good Business Analyst will ensure that regardless of your approach or tooling; they'll capture and convey the requirements appropriately.

I have a dream...

that one day all business users, IT folk and software companies will model their processes in a consistent way in order to design their systems appropriately.  It will be a common language that is not only intuitive and well understood but integrated through to system design and back.   I just don't think that day is today and hence for today, we're reliant on Agile methodologies or great Business Analysts (or preferably both together).

Edit: What’s wrong with BPMN for Requirements Elicitation

I realised after I posted this that I missed thisfundamental section to my blog. To at least give some background to why I think it misses the mark I’ll make the following observations:

• Unlike EPC, BPMN is less structured and open to different approaches based on your background. Maybe a clear standard on implementing BPMN from a requirements perspective may fix this.
• Some of my requests for the tool could address many of the other problems I have with BPMN such as being able to view the processes in isolated ways to not overwhelm the business.
• BPMN is quite clearly a type of programming language and hence forces this style of thinking onto the business.
• It’s not abstract as it usually becomes an execution language.  I believe in UML that you split up logical models verses design models, and that is really powerful for communication. Sometimes logical and physical can be quite different. 
• It doesn’t have many obvious business interactions icons. 

I have to admit, I haven't reviewed ARIS recently to see what they have done in this space as we currently use Enterprise Architect for our early modelling needs but the tool really shouldn't matter that much should it???

Introduction

Firstly, please bare with me while I give a quick run down of my career titles and sorry this sounds a little like a CV...I am happy in my current job, but this is just to give my view point on what has happend with the term architect within the software industry over the last decade or so.

The History of My and other Architect's Titles

I remember when I worked within the R&D department at a hardware/software company that made digital audio workstations (Fairlight).  My title was Software Engineer and no matter how experienced I would have became there, the most my title was ever going to change was to Senior Software Engineer. 

Coming out of an engineering degree, this suited me just fine but I definitely appreciated that there was a lot to live up to with the title Engineer.

A few years later, after I'd left that company and joined an SAP consulting house; the Engineer was stripped from my title and replaced with consultant styled titles (Consultant, Senior Consultant, Manager, etc).  Everyone had this title so although a little dull, it sufficed for this role.

Now forward a few years to around 2000, and my title was now Technical Architect.  At this point we started getting functional and technical architects within SAP (basis was still basis around the 4.6C days) so a technical architect was more from a development perspective.

Then NetWeaver came out, databases got more complex, SAN technologies and virtualisation were introduced, and Basis people needed to become architects just to design and maintain their landscape. They took the Technical Architect name, and for some reason, we never really introduced a development architect so that got confusing for me for a few years.

Then TOGAF and other enterprise frameworks started to get big so Enterprise Architects became all the rage.  Not to mention the confusion that SAP did when they introduced Business Process Expert which suprisingly didn't have the term "Architect" in it (how refreshing). 

At this stage, I believe BPX and Business Process Owners has started to replace the Functional Architect title. 

It was about then and when SOA became big that the "development" architect evolved into the Solution Architect title - especially those who could grasp all the products that were hitting us at that point (does everyone remember all the xApps being talked about in 2005 or ESOA for that matter). 

So with that snippit of history in mind, where are we today with the term Architect?

So what is an Architect and does it seem to you that everyone is an Architect now?

(I won't answer the second question of this section, but let's describe what I believe is required to be an architect.)

Regardless of what type of Architect you are (excluding the more traditional kind), be it Solution, Enterprise, Business Process, Data, Technology, NetWeaver, Integration/SOA, Portal, CRM, BI. SRM, etc; there are certain characteristics that I believe you need; and a few more that are nice to have.

The mandated characteristics are:

• Knowledgeable in your area of expertise with hands-on experience - no Sales people please;
• You're never too introverted to give an opinion;
• If you don't know the answer, you know how to get it; or know when you're on your own to work it out;
• A constant drive to keep up to speed on the latest developments, trends and best-practices;
• Willingness to try these new things ensuring minimal risk, and even championing them into production when appropriate;
• You have the ability to mentor in order for your designs to be achieved (I'm not saying you are patient when doing this, but it's a requirement of the job).

• You share information beyond your enterprise and realise the value of community;
• The boundaries of your role description, don't stop you wanting to learn more.

So why this Post?

Everywhere I look now, I come across "architects". It's the buzz word for senior consultants and if everyone had the above characteristics I would have no issue with this but this is not always the case. Hence, if we are to keep the term architect to reflect a senior capable and knowledgable role; I'd like to ask the following of all those that have been rewarded with the title Architect: 

• Please review my mandated characteristics;
• let me know if I've been too harsh, or if other characteristics are required;
• If you are missing any mandatory requirements, please work on these and let's keep the Architect title being a well respected title.

What's the Alternative?

Well IT Architect's are relatively new so we could use something different.  We have engineers still in many places but that doesn't seem to work in the consulting world...We could start to abuse the term Doctor, and the "Enterprise Doctor" does have a certain ring to it (strangly enough, I did get the nickname "Doctor 9-pin" at Fairlight when it came to fixing issues with Sony's 9-Pin protocol for controlling Video which was, like most standards, implemented differently by everyone)!

In my mind, this isn't really an alternative. Apart from Solution Architect (it seems), we are starting to settle down on the definitions of the various types of Architects, so lets keep an eye out for architects that don't architect and make sure we let the various vendors/managers know our expectations so they don't make architect's out of senior consultants too early.

Introduction

I've titled this a garage sale (or yard sale as my US colleagues would say) as it's a real mixed bag of topics that are related in some way that I want to sell (I mean discuss but it ruins my analogy). It's pretty broad in terms of covering business process, methodologies, SOA and development, but if you are BPX'er with some technical savvy or a Solution Architect (Functional or Technical) then please read-on as I'd love to nail this with a decent discussion and potential future follow-up in another blog.

My reason for writing this blog is to put forward some ideasto try cement a direction for those who work for organisations where software development is not their core business and where they are bombarded by all thebest practices out there right now.

Background Information

So if you're like me, you know or believe that:

• Modelling is a great way to work with business processes and Business Process Modelling with tools like ARIS is considered a greatway of starting to measure, improve and document your business processes;
• Agile methodologies like Scrum are now beingseen as the bees knees of development methodologies;
• SOA is no longer a consulting marketing dreamand actually is starting to be understood in terms of where it adds value and where it does not;
• SAP's NetWeaver BPM (Galaxy) is being positioned as the BPM engine for SAP, not replacing PI/XI but providing the cross system workflow tool with a business process view of the world. It's not a business tool as such (I still can't see myself asking business users to install Eclipse) but does allow us to visualize workflow cross systems much better thanif we were to use SAP workflow calling Web Services).

Now you're CEO and CIO are quite possibly telling you that they want SOA, BPM(odelling), BPM(anagement) and I want it done in an Agile way; where do you really start when you have a new business application implementation/development????

Good question and hears a few reasons why...

Problem 1

We still have our external consulting companies wanting to implement waterfall methodologies so they can lock down requirements prior to implementation.  Even if we did allow them to run their projects using Scrum or similar, we may not be ready yet to trust them to do this either from their Scrum maturity perspective or wedon't have someone we intrinsically trust within their project team to act as the lead designer/architect.  Another option may be to put one of our architects on the project to give them the agility they require, but that assumes you have enough architects to go around which is usually not likely.

Problem 2

Now we need to start mapping all our as-is business processes in order to develop our to-be world; but hang-on - If I want to do this in aScrum way, must we at least finish our as-is modelling before we build our product backlog or can we just focus on one process area.  I'm wondering, can process modelling be done in the same way as code, and be re-factored each release on the fly? Are we just going to confuse the business too much if we try this or are we goingto make way too many assumptions if we do this?

Note – I’m no BPM expert, but I do know we also need to also consider the lifecycle of BPM as too many BPModelling exercises end up as a very expensive once-off documentation exercise.  That said, I’m not going to address the business buy-in or tool aspect of this issue, just the methodology component of it.

Problem 3

So we want to implement SOA because we know integration costs are huge. But what I believe time has told us is that without a comprehensive to-be BPModelling exercise, we're in danger of leaving the identification of suitable reusable services to our techies when this really requires business and techies coming together. (For reference, I believe there are many scenarios where it does not make sense to make an interface a reusable service.)

Problem 4

We now have NetWeaver BPM in our back pocket as a great technical tool (for reference, in its current incarnation, to me it's more ofan engine for cross-system workflow). We really want to use it for BPManagement to measure and improve processes through what-if scenarios based on real information but we don’t want to have to pull our processes out of our key systems just to do this.

That’s our last problem for today (I’m sure there’s plentymore).

So what to do?

Okay – This is where I’m going to propose an approach which is very specific to an organisation that works in an outsourced environment,has settled on a base set of applications/technologies (like SAP), but holds governance centrally with an insourced team of architects who have way too many projects on the go at once to be heavily involved in more than 1 or 2.

Pretty common with all Agile methodologies is a good understanding of the high-level requirements prior to coming up with ac andidate set of iterations or sprints. You really need this to understand the kind of solution architecture at a high level so that you can also have an idea of the scope and what is practical to be done in the timeframe.

So building an as-is business process model for the area associated with the project is definitely worthwhile prior to commencing the project.  Now over time, the fullset of impacted business processes may be captured already, but initially, you won’t have this information so we need to do this if we’re serious about changing the processes in this area in a measurable way.  Obviously, from a consulting companyperspective, any company will have no problem in doing this exercise.

Now if we started to do the to-be processes; we’re going to be constraining the development too much from giving the maximum benefits, so really this is where we need to scope the high level requirements and at least understand the potential impacts to the existing processes.  This to me is a pretty short and sweet document that captures in table format, components that can be leveraged to build your storyboard.

Now it’s time to plan our iterations, but what are we going to do with our consultants...Okay – Big risk here, but I’m recommending you take an important project and do the following:

• Put one of your internal solution architects on this project for at least 40% of their time if not more;
• Get a Scrum mentor from a consulting firm with proven experience (usually a niche consulting firm) – they could possibly actas the ScrumMaster for the life of the project, but preferably not.
• Engage your most trusted consulting company in a time & materials way but ensure you get the right resources for the project, including a similar Solution Architect who will mirror your Solution Architect (and run future similar projects without your internal Solution Architect).
• Sell the idea to management, telling them that we can quickly shut down the project if we don’t show progress due to the agile approach and how isn’t that better than typical waterfall projects (they’re kind of board already aren’t they?).
• Get to work...

So with this approach we now have the iterations/sprints planned, we have a high-level architecture that has been ratified internally and we’re ready to start developing.

Now being Agile, we have at least the following deliverables every iteration/sprint:

• Our tested production ready code/configuration
• Design documentation
• Test Cases
• Training material

And here’s where it’s different (and possibly a little more annoying):

• To-be business process models for the current iteration changes (and version managed appropriately since your changes are not yet released)
• Requirements mapped to the process models
• Requirements mapped through to our test cases (I’m assuming our testing will remove the need to map our requirements our functional design)

In terms of the to-be business processes; we need to differentiate iterations/sprints from a release.  i.e. Although we have a perfect piece of the business process at the end of an iteration/sprint, we would not want to give it to the business till it is stable.  Worst thing ever could be to put a business process change into a call centre every 3-4 weeks.

At the end of each iteration/sprint, governance steps can take place, but the assumption is that with your own solution architect involved, there should not be too much requiring refactoring in the next release.

So that gets us past Problem 1 and 2 with hopefully you not being fired (even if it goes all wrong, there is no way this will have a cost blow-out as it can be stopped quickly due to it’s agile nature and focus on quality).

So how to deal with SOA…Well we’ve compromised here.  We’re doing to-be models, but unless we leave all integration to the last set of iterations/sprints (which is a verybad idea), we’re going to have to take some short-cuts.  So basically, as you do the restricted to-be modelling, it’s important that every interface get reviewed by the solution architect and they need to ask questions of the business like the following: 

• Is this interface an out of the box interface?(no point re-inventing the wheel just to make it service enabled at this point)
• Do you foresee this type of interface being ableto be leveraged elsewhere in the future if we write this more generically?
• Is this target application likely to be replacedin the next 5 years?
• Etc.

So pretty lame answer to problem 3, but there you have it. The better your Solution Architect knows your business, the better the outcome of this.

Now problem 4 I put in there as I had an interesting discussion with Oliver Mayer at Inside Track –Sydney…Basically, IMHO SAP’s NetWeaver BPM is lacking a really good business case for just doing it within an SAP environment.  But what if they enhanced the functionality of the solution to also allow it to track business processes that take place within systems? Think about this for a minute.

You basically have your to-be model; you import it into NetWeaver BPM, configure your cross-application workflow or workflow for systems without workflow, then for all processes that take part within the system, you expose an API to allow that process to be monitored and measured.  Eg. Within an enhancement point, you call out to BPM Galaxy through an async call and set a date/time with a key to identify the specific process and measure that process.

May take quite a bit of playing to make it work, but then we have true BPManagement happening where we can start to play with what-if scenarios with our processes to make significant process improvements.

Anyway, just a thought that sounds awesome to me.

Thoughts? 

So obviously I’m not a Business Analyst and I’m looking through a pretty specific lens, but if you’ve got this far, have you suffered the same dilemma and come up with a working solution?  I would love to hear your thoughts.  I haven’t got into detail about how BPMN vs EPC or how you captured detailed functional and non-functional requirements plus the tools required to map these to test cases but maybe that will be my next blog when I go down this path.