While there are a great many resources that detail Agile methodologies on the Internet I’d like to give a real world example of the kind of advantages that I have experienced in using such an approach.

Recently I have been working on a project for a global telecommunications company to replace their catalogue management solution. The existing solution was not providing sufficient control over the process, and had proved cumbersome in productive use. Therefore we had a reasonable baseline of what a new solution should deliver, although this mostly revolved around what it should not do.

By adopting our iterative approach (see diagram) we quickly put a baseline solution together. While not the finished article, this gave the stakeholders an early look at something tangible within the Playback Review. This allowed them to provide focused feedback and at the same time we could develop some further clarity on their requirements. For example it became clear that the new solution should have a catalogue download function, as this would fit in well with the users way of working.

Our next iteration incorporated the feedback and newly clarified requirements, this was again reviewed by the client. By going through a number of iterations the number and size of bugs and gaps in functionality is reduced. In this example we identified that the format of the catalogue download should match the catalogue template which the users exchange with their suppliers.

By the end of the Realisation phase we had ironed out any bugs and requirements gaps, and had a fully usable solution which the key stakeholders had bought into. If we had been using a more traditional methodology this may have been the first time the stakeholders would have seen the solution, which could have led to costly rework because of differing interpretations of the initial requirements and potential delays.

This is probably a fairly familiar situation to most of us, in that there was an idea of what needed to be delivered but not a complete picture of what the final solution should look like. By utilising an Agile approach we had sufficient flexibility to adapt to evolving requirements. We could also engage stakeholders at an early stage, building confidence that the correct solution was being delivered and ultimately providing the client with a solution that matched their needs.

It is important to note that we adopted this approach within a formally phased programme (using a Waterfall methodology). By knowing how far to extend Agile methods within the wider framework of a phased project the client was able to reap the benefits of an Agile realisation phase with the governance afforded by the Waterfall approach.

So why doesn’t everyone work in this way? Well not every project will be suited to this approach; for example it particularly benefits projects that deliver user facing solutions as you can bring end user feedback into the solution at a very early stage. But more importantly this approach requires a particular set of skills, as the teams working in this way need both the technical skill set to deliver functionality quickly and flexibly, as well as the ability to work closely with stakeholders and end users, set out a viable vision for the solution that resonates with the business need, adapt to feedback on each iteration and drive the prioritisation of functionality that delivers the best results for the client. Being able to do all of this without the safety net of detailed functional specifications is not a natural skill set for Technical Consultant – that’s what the ‘Agility’ in AgilityWorks really stands for.

You can read more about our approach to project delivery here.

Smart organisations now treat data as an asset. Though it is hard to put a price on, the quality of an organisation’s data can affect its performance in the same way as other asset classes.  As data supports and underpins all business applications poor quality data can lead to far-ranging negative consequences.  As the old saying goes, ‘Rubbish-in, rubbish-out’.

Benefits of Mature Data Management

If an organisation’s data is the basis of its decision-making, there is an immediate benefit to performing a data quality exercise. It will increase the confidence and the accuracy of any analysis based on the cleansed data. This can have a significant impact on exercises such as project cost-modelling and aggregate spend analysis where minor variances can add up to major decisions.

Improved data quality can also improve process efficiency within an organisation. To illustrate let’s take the example of a vendor payment that fails due to incorrect bank details. This could result in a series of re-work tasks, all of which could be avoided if the error was identified before the payment run. The scene might appear trivial but the cumulative effect of such non-value added activity can be significant.

Case-Study

AgilityWorks is currently working in partnership with a global telecommunications company to pilot an integrated data quality solution across several data objects and functional areas.  The solution fully incorporates data quality management in the enterprise architecture. The client is able to monitor and evaluate the on-going quality of master data across key business functions. This is coupled with a process to remediate data quality issues by exception as and when they arise. To achieve this AgilityWorks has employed the following approach:

1. Initial data quality analysis By performing an initial investigation of sample data, AgilityWorks worked with the client to demonstrate the current shortfall in data quality and build a case for improvement.
2. Define data quality standards By working with and aligning different business areas, precise data quality standards were laid out in the form of business rules against which the quality of data could be measured.
3. Introduce data quality within the system landscape By exploiting SAP Business Objects Data Services 4.0 to consolidate data from a heterogeneous data environment and SAP Business Objects Information Steward 4.0 to write and process the business rules, a complete data quality solution was integrated into the existing landscape on a single platform.
4. Introduce data quality to the relevant stakeholders By identifying the needs of stakeholders, AgilityWorks was able to work with the client to ensure that targeted reporting was created to support a robust data quality process. Two sets of stakeholders were identified: managers of the various business areas who relied on the data being analysed and data stewards whose role it would be to review and remediate the exceptional data items.

At a managerial level the reporting requirement was to give a visual overview of the situation. This enables the identification of problems and means that the progress of improvement activity can be tracked over time. To facilitate this, summarised reports were produces using SAP BusinessObjects Web Intelligence 4.0.

At a managerial level the reporting requirement was to give a visual overview of the situation. This enables the identification of problems and means that the progress of improvement activity can be tracked over time. To facilitate this, summarised reports were produced using SAP BusinessObjects Web Intelligence 4.0.

At data steward level the reporting needed to pin-point the most effective areas for remediation, before allowing users to drill-down to the line level data. The scorecard in SAP BusinessObjects Information Steward 4.0 was chosen as its content could be pre-defined by the business, both in terms of what metrics analysts should see, and the importance that they should place on them.

Conclusion

So is data an organisation’s greatest asset? Well, at least one thing is clear. Poor quality data is an organisation’s worst nightmare. From decision-making to everyday processes, data permeates all aspects of business. Therefore smart organisations recognise that they need to take a proactive approach to data quality, one that combines business focus with leading data quality tools.

Will Flash developers simply move to the AIR platform (which remains very much part of Adobe’s mobile strategy) and migrate their flash content into Mobile apps? With HTML 5.0 gaining more and more traction as it emerges as ‘The next big thing’ I think many Flash developers might be wondering whether it might be time to graze on pastures new.

This must be what Adobe is suspecting as they’re not just committing to AIR, they’re also committing to HTML 5.0. ‘Adobe® Edge is a new web motion and interaction design tool that allows designers to bring animated content to websites … ‘. Sound familiar? Of course but this time it’s not a Flash tool, Adobe appear to be re-inventing themselves in the web arena and they seem to be taking HTML 5.0 rather seriously by virtue of their Edge development environment.

Adobe are certainly not alone, SAP’s UI strategy for 2011 is peppered with references to the technology, and not just in the Enterprise Mobility space either. Microsoft too seems to be hedging their bets with Windows 8 which will feature HTML 5.0 and JavaScript based user apps. 2012 is certain to see much innovation with HTML 5.0; it continues to deliver value to the enterprise and will no doubt find a welcoming home in many long term mobility strategies.

It’s not all about User Interface

It isn’t just about what HTML 5.0 and associated technologies can offer in terms of User Interface. Local storage and offline capability are the building blocks that could start to position HTML 5.0 as a more complete mobile application framework that isn’t quite as reliant on other technologies. And of course it is open standards based; one initial investment can be re-realised on myriad platforms with much less re-investment than for mobile applications that rely solely on native code.

Think about an application that requires you to capture say, detailed customer information, validate it and then display it in other parts of the application. Natively designed information capture and display forms would need to be written from scratch for each platform you wanted your app to work on (iPhone, Android, Blackberry etc.). HTML forms can be re-used (and even re-branded if needed) across these platforms saving you significant amounts of development effort: Write once, use many times means greater ROI.

I don’t mean to imply that HTML 5.0 can always be fully independent of native implementation; this is an unlikely scenario when building mobile apps for the enterprise. But, the opportunity may quickly arise for HTML 5.0 to play a much more prominent role in mobile enterprise application building and you’re not going to have to plan for dependencies on third party plugins such as Flash nor worry about any compatibility/performance issues arising etc.

Back to reality

HTML 5.0 isn’t a fully recommended W3C specification yet, but this hasn’t stopped the browser vendors from implementing its features. This is generally a good thing because it means we can already start to innovate and realise the value of the technology.

Estimates on timescales to full specification have reduced from 2022 to 2014 which is very encouraging and means it shouldn’t be too long before mobile browser vendors can start to reference what they’ve implemented against a much more complete specification. Standardisation is important because it gives added assurances about the robustness of the technology and enables vendors to implement features faster and with greater stability. The more features that your apps can leverage the more value they can add.

Will mobile flash be sorely missed?

I wouldn’t imagine smartphone/tablet users are going to miss Flash too much. HTML 5.0 certainly promises to supply the tools to continue in the vein of rich immersive web content and user experience. Plus developing with HTML 5.0 is going to realise cost efficiencies for your business: no need for proprietary development environments and associated licence fees.

Whilst perhaps still in its adolescence, the technology is maturing quickly and certainly has great potential for Enterprise Mobility. Marry HTML 5.0 apps with SAP Unwired Platform to synchronise the data you need and secure them with Afaria Mobile Device Management Platform; you’ll soon find yourself leading the way with a solution delivering the benefits that your corporate peers are all looking for: reduced time to implement, flexibility, higher return on investment, scalability and security to name but a few.

But before we look at these scenarios, we need to first understand what is HANA.  The HANA acronym stands for “High Performance Analytical Appliance” and it is essentially a database that utilises in-memory technology. I am not going to go into the technical details of in-memory database technology (we could be here all day), but what it is good at is the superfast aggregation and reporting of large volumes of data that changes frequently. So hence we get the “High Performance”. Now what does the “Appliance” bit mean? The HANA application is delivered fully installed on a server (or servers) by certified hardware vendor. This means customers don’t need to worry about system setup, but can basically “plug & play” when the server arrives.

So what’s in it for those who don’t have SAP already?

Let’s look at an organisation which is not necessarily a SAP BW customer, but has a very agile reporting requirement that involves large volumes of data. HANA provides a platform in which they can develop their own reporting database and load large volumes of data and quickly report on this data. Granted this sounds a lot like what many customers do with standalone databases today and it is, but this is an in-memory application so the performance implications are the selling point. And to be fair, the benefit is not only performance gains, but also simplifying their landscape (no need for separate aggregated data marts) and enabling users to ask questions of large data sets which were previously not possible.

There are a few additional topics within this example that need a mention here. Firstly, the recommended approach would be to use BusinessObjects Data Services to get data into HANA and secondly BusinessObjects BI4.0 would be the reporting applications used to query the data residing in HANA.

Diagram 1: SAP HANA for Customer without SAP

Already have SAP BW?

Now let’s take a look at an organisation that has already deployed SAP BW. To understand this scenario we need to understand that HANA is not a replacement for SAP BW. BW is an application designed to build and maintain an Enterprise Data Warehouse. HANA is a database. Don’t get me wrong, as far as databases go it has great potential in the analytics arena. But today it is not going to replace BW, it is designed for something entirely different (remember we mentioned the superfast aggregation and reporting of large volumes of data that changes frequently). So what is the co-existence between HANA and BW?

For those wanting to immediately benefit from the performance of HANA, it can be deployed alongside an existing SAP BW system or even a SAP ERP system. In both instances data is loaded into HANA to enable high performance analytics using the BusinessObjects BI suite of tools. However, there are slight variations in how data can be loaded into HANA depending if the source is BW or ERP. For BW, BusinessObjects DataServices is used for the mass scheduling of data loads from BW into HANA (this could be part of the batch jobs that load data into SAP BW). In the case of ERP, SAP’s Sybase Replication Server can be used to load data in real time into HANA enabling right time reporting.

Diagram 2: SAP HANA for SAP Customers

What’s next?

Simply, we are going to be able to run SAP BW 7.3 on this in-memory database. For those of you familiar with the BIA, this is like saying the whole of BW is going to be in or on an in-memory database, replacing the existing database  that your BW systems runs on currently. But is this a good thing? Well, for starters, you get everything to build an Enterprise Data Warehouse courtesy of SAP BW 7.3. Not much change here for existing SAP BW customers, but before we move on let’s remember one of the big benefits of customers running SAP BW and SAP ERP (or any of the other Business Suites), is of course SAP Business Content. This is an important difference between HANA 1.0 and the next release. Unlike, HAHA 1.0 which would require a few “middleware” components (as mentioned above) for data extraction and replication into the database, we will now be able to leverage those standard delivered extractors to get data out of SAP source systems and into our Enterprise Data Warehouse. And our EDW is now entirely in-memory. So theoretically we are ensured of great reporting performance over large volumes of data. Well that’s the plan anyway!  For those BW customers who are looking to move to BW 7.3 or who are indeed already using BW 7.3, apparently the migration path to HANA will be very similar to the current database migration process.

With mobility fast becoming a key focus area for many organisations around the globe, some concepts that are unique to mobility need to be considered when deciding on a mobility solution. One such consideration is data Synchronization.

Most of you already understand what we mean by the term “Synchronization”. To the benefit of those who don’t, let me give you a simple example: There is data in the backend system which has been sent to the device, now when this data changes/updates or new data is created on either end, data needs to be synced so there are no discrepancies between the backend system and the device.
This is called Synchronization.

Synchronization in SUP can be achieved in two ways

SUP supports two kinds of Synchronization techniques:

- Replication Based Synchronization (RBS)

RBS is based on the technique of issuing a pull from the device to fetch the data from the Cache DB on the SUP server (This is where all data from the backend system is replicated by the SUP server and cached to be sent to the device). This can either be achieved through a user initiated data pull or a timed pull depending upon the nature of the data and replication requirements. A third option known as the “Poke-Pull” model can also be used where a notification is sent to the device to initiate the data pull.

- Message Based Synchronization (MBS)

MBS is based on the technique of a  push from the backend, so whenever there is a data change in the backend system, it is always pushed out to the device.

A mobile application can be either message-based or replication-based, but cannot be both at the same time. A package of mobile business objects (MBOs – are Data Objects created by SUP to model your backend data) can be deployed as either message-based or replication-based.

Efficiency and Data considerations

RBS is efficient in situations when your device stays in offline mode most of the time, so that when there is a connection you can synchronize with the backend data. It is also very efficient with bulk transactional data which can be uploaded in a single sync.

MBS is very good for devices in online or connected mode, as they keep receiving instantaneous updates. Each transaction is however considered as a single message so it is not very efficient for bulk data.

Another big difference between RBS and MBS is freshness of data. With MBS this is considerably high as updates are received as soon as your device comes online or a data connection is restored.

With RBS, unless the device initiates a sync, the data on the device will not be updated and will retain an old state which over time will become inconsistent with the backend.

SUP and Devices

Well the device is also a concern because SUP does not support RBS and MBS for all client devices e.g. iPhone/iPad (iOS clients) only support MBS and not RBS, whereas Blackberry(RIM) on the other hand  only supports RBS.

Staging of data

With RBS, data that is to be mobilized is copied to a consolidated database on the SUP Server before sending it out to the device. This is known as Data Staging and results in Data being stored on a Cache Database (CDB) on the SUP server.  An architectural requirement is needed for this synchronization model. For MBS, data staging is optional.

Device Registration

With the RBS model, device registration with the SUP server is implicit, meaning the first time the device connects to the SUP server it gets registered, whereas with MBS the device has to be explicitly registered at the SUP server before it tries to connect.

Summary

The points discussed above constitute some key differences between these two techniques.  So based on the enterprise requirements, a careful decision needs to be made as to which of these techniques to adopt, and what the device supports.

To sum up both techniques have their pros and cons, so depending upon the data and the device, the enterprise has to take a balanced decision on which technique to use with SUP, because this is a very important initial step towards building applications with SUP.

The vast majority of SAP’s BPC development effort over the last three years since its acquisition of OutlookSoft has been to build tighter integration with its corporate data warehousing platform Business Warehouse (BW). It also announced at the beginning of the BPC development journey the end of maintenance in 2018 of its Integrated Planning (IP) application which is delivered as an integral part of BW.

SAP’s strategy for Enterprise Performance Management is clear – BPC is the future of planning for its customers. So the decision for customers to implement their planning solutions using BPC is simple then. Well maybe not. I believe that the answer is not quite so straight forward – based on where we are today in the BPC development journey, the actual answer is that it still depends.

What Type of Planning Application is it?

This depends on a number of factors that should be considered carefully before you come to the same conclusion as SAP. Firstly and most importantly, what type of application are you trying to deploy to your business? BPC was originally designed specifically to support financial planning applications and has built in accounting intelligence and data models to support them out of the box. That’s great but if for example you want to build a non-financial application BPC still expects your data model to contain key accounting dimension elements such as account, category and entity as a minimum and be based on specific BPC application types – financial, consolidation or generic. It also only supports an account based data model using a single key figure.

Now I’m not saying that this precludes you from building non-financial applications but consider for example a supply planning solution where you require multiple units of measure depending on material type. You are going to have to work a lot harder to build that solution using BPC than you otherwise would using IP where handling multiple units of measure and on-the fly conversion is a given.

Excel or the Web?

One of BPC’s greatest strengths is its complete integration with Microsoft Excel – in fact BPC can really be seen as an extension of it. So if the application requires the use of the Excel UI and native integration with other functionality then it’s a no brainer. It also has very powerful features for building distributed planning solutions where users can chose to take their planning workbooks off-line and standard Excel input schedules can be generated which can be automatically collected and loaded back into BPC at a later stage.

If however, you need to build and deploy a zero footprint Web based solution for example through the SAP Enterprise Portal (EP), then IP currently offers the ability to develop a far more comprehensive and integrated solution. This is set to change with the next version of BPC which is part of SAP’s Enterprise Performance Management (EPM) 10.0 release due for general availability in Q1 of 2012. This delivers a completely revamped UI with a significant emphasis on a new Web client which has been long overdue.

Self-contained or Integrated?

BPC has a dedicated namespace for each application set within the BW environment meaning that all data objects, both master data and transactional, are independent of those contained within the rest of the data warehouse. One of BW’s strengths is the use of a shared data model meaning that key master data objects can be updated once and a common and consistent view of those objects is provided to all transactional data. When deploying a BPC application consideration needs to be given as to how much and how often master data and transactional data needs to be moved in and out of this separate namespace.

If the application is largely self contained and data is only moved in or out at specific points in a process then this does not pose a problem but what if we need data to be moved in and out more frequently (e.g. daily, hourly or near real time), then this becomes more of an issue for the overall application design.

What’s the Reporting Strategy?

This separated environment also influences the reporting strategy adopted. If a strategy of BEx Analyser or BEx Web Analyser has been employed which the business wishes to retain then again we need to move our data out of the BPC environment before we can report it. Currently it is not recommended to report directly from a BPC application using BEx due to technical constraints and the added complication of separate master data objects when wishing to present a combined view of transactional data from BPC and BW data sources.

Business Objects BI tools such as Xcelsius, WEB Intelligence and Advanced Analysis are supported by both BPC 7.5 and BW and this provides us with the best strategy for ensuring business users adopt a common UI for all but this obviously has additional license and implementation costs if adopted.

How big is it?

For me the key question which still needs to be answered is BPC’s ability to scale. If your predicted data volumes are large then do you really want to be confined to a single account based transactional data cube? BW-IP gives us a range of tools and techniques to design and tune our applications to handle high data volumes. SAP will address this in BPC through the use of their new High Performance Analytical Application (HANA) which BPC version 10 will begin to exploit but again this means additional cost to solve a problem which BW-IP can do out of the box.

Scaling in terms of user volumes however is a little more straight forward. As we have discussed previously, BPC offerers us functions and features to create a distributed planning application which will scale to many thousands of users but what about if we need an on-line application for the same user base?

Can you justify the initial cost?

One fact that cannot be over looked is the challenge in defining the business case in terms of additional license and maintenance costs for existing SAP customers with significant investment in BW.  Again I come back to looking at BPCs functional strengths and its key differentiators from BW-IP.  If the application which you are looking to deploy plays to the strengths of BPC then it is a relatively straightforward exercise to justify the increased costs of the initial implementation but if not then it must be seen as a strategic investmemt as much as anything else.

In summary, BPC is the future for planning applications within the SAP domain – SAP themselves have already made that decision for us but the question which must be addressed by existing SAP customers who do have an investment in BW is when does it make sense for them.

Mobility Spectrum

Sybase Unwired Platform provides developers and the enterprise with the components and tooling to deliver three distinct categories of mobile applications

The contents of this blog is premised on a standalone deployment model for SUP with MBO’s bound to a Web Service data source.

Providing offline capability into a mobile application is centered on the secure and efficient exchanging of enterprise data between a device and the backend whilst maintaining synchronicity. Looking back, the more I became acquainted with the development patterns for building SUP native apps, the more I thought that the name “mobile synchronisation app”(apart from being a title Sybase have given to a category of mobile apps) elegantly describes the value SUP offers to developers faced with building offline capability into a mobile application.

In my eyes, the key value proposition of mobile synchronisation apps is its ability to abstract from the developer a significant portion of the complexities associated with building synchronisation and security logic into a mobile app. These complexities include creating the database (on the maiden launch), performing an initial data load, enforcement of distribution rules, security access to enterprise data, etc. Traditionally, synchronisation logic alone can account for at least 60%-70% of the effort required to build offline support into a mobile application. (A bold estimate?? Not so when you consider that synchronisation must cater for scenarios such as: what happens when the connection drops; what happens when a collision is encountered; what distribution rules need to be applied i.e. who gets what?)

Three Box Architecture

Before explaining how SUP can simplify the development of secure enterprise grade mobile applications, let us first consider the architectural components that comprise a typical SUP mobile synchronisation application – or what I call the “three box architecture”.

On the left we have the enterprise data source. Think of this as the enterprise information system (e.g. SAP CRM) that houses the enterprise data that is to be mobilised. In the middle is the aptly named middleware. Conceptually, a middleware allows the mobile solution to decouple itself from the enterprise backend whilst providing the capability to handle scalability and synchronisation factors, by providing a staging area for enterprise data. In an SUP world the middleware translates into the two key components: the Sybase Unwired Server – middleware management server and central console; and the Data Tier – a highly optimised DBMS fine-tuned for mobile applications (referred to as the Consolidated Database (CDB)). On the right we have the physical device. This is the platform on which the enterprise mobile application will run. The central difference between mission critical apps and its counterparts is that, whilst instant value apps and hybrid apps would typically fetch data over the air before it presents it to the user (hence online apps), mission critical apps will interact directly with its native database. Therefore the key to a successful mission critical app is its synchronicity with the backend (and hence the name “mobile synchronisation apps”).

Cache Synchronisation

So what exactly is the Sybase Unwired Platform solution to the challenges surrounding “offline” support for mobile apps?  The answer is through a concept known as cache synchronisation. As the name implies this form of synchronization uses the cache as a mirror of what users see on the device. While the cache is not the system of record, it serves as an intermediary to allow the server to compare the last time cache elements were updated with the time the specific data elements on the device were last successfully synchronized. This mechanism allows the server to download only the elements that have changed since the last time the device synchronized.

Loads V.S Sync

One of the fundamental concepts to grasp with this thee box architecture (in which data is staged within a middleware CDB technology) is that there is a clear distinction between data loading and data synchronisation. Data load occurs between the data source and the middleware whilst data synch occurs between the middleware and the device.

There are typically two approaches to serving up enterprise data from a data source to the CDB. Data can either be “loaded” or “pushed”. Loading implies a pull of data from SUP and results in a refresh of the MBO contents within the CDB. Loads can be triggered either on demand (each time the user triggers a sync) or as a scheduled task (automated by SUP). In both cases, a load will request from the data source a snapshot of what the contents of the MBO should be. The CDB then performs an intelligent* comparison of the response set with the current contents of the CDB set and adjusts the CDB accordingly. A Push on the other hand implies that the data source pushes an instruction to the CDB to update, insert or delete a record pertaining to a particular MBO. In the case of a push, the CDB is not refreshed but rather maintained by way of pushing out deltas to the middleware to be ready for the next device sync.

Synchronisation for the most part is delivered out of the box with SUP… and is where the real benefits of the Sybase Unwired Platform come to bear. When data is served up to SUP, the CDB will mark all records that have changed following a load or push as “awaiting sync” so that when the device next synchronises, only marked records are transferred over the air to the device. At same time, any changes that are made to an MBO on the device are synchronised back to the CDB. In the case when data is replicated backward from the device to the to the CDB, SUP will trigger an update to the data source to ensure that the data source either creates, updates or inserts the new record.

*Using a primary key as a comparison point, the intersection of the response set and the CDB set will be updated whilst the symmetric differences will be either inserted or purged.

1. Eclipse is coming – with PI development joining BPM, Java WebDynpro, SUP on the Eclipse IDE, and even talk of ABAP development moving to Eclipse, a truly integrated development for SAP is no longer a distant pipedream. This will require some upskilling for those previously focused on PI or ABAP in the native tools provided by SAP, but this move will make cross training across different technologies a lot simpler in the future.

 

2. Project timelines are getting shorter – SAP projects can no longer be measured in months, the rise of mobility and the rapidly changing business landscape has caused a paradigm shift in expectations. This can be seen with SAP now supporting agile development through a ASAP plug in for SCRUM, and the speed at which mobile apps can be developed ably demonstrated by the SAP Trainrace. That is not to say that large scale ERP roll outs can take place overnight, but that real business value can be delivered quickly and effectively with SAP technology.

 

3. SAP BusinessObjects Data Services has come a long way – having a background in SAP integration and data management I could see a lot of potential in the latest version of Data Services on show at TechED. Ranging from the ability to interpret sentiment in unstructured text to providing the data quality engine for SAP BusinessObjects Information Steward. As well as building on its ETL roots as the backbone for ‘big data’ in the Enterprise through the loading of data into SAP HANA solutions (okay I couldn’t quite avoid the ‘H’ word). Data Services can really drive some interesting analytics and provide ‘next generation’ ETL capabilities.

 

4. The Sybase acquisition was not just about mobility and databases – There are a number of other gems in the Sybase portfolio, not least the Complex Event Processing Platform used in a new Business Activity Monitoring (BAM) tool I saw demonstrated with SAP NetWeaver BPM. This was able to be configured on top of existing processes without changing the pre-existing development and potentially has scope to include monitoring of events in other systems and provide real time dashboards of business processes. While this is not due to be released until late 2012 and is no where near a defined product yet (and could well be completely re-architected by the time we see a Ramp-Up product) it was a very interesting concept.

 

5. Cloud Computing – the ‘other’ theme at TechED, with Mobility and SAP HANA ruthlessly hogging the limelight it would be easy to forget this third main theme from TechED. With SAP releasing a number of OnDemand solutions and entirely new cloud based products (SAP Streamworks and SAP Information Interchange), as well as the SAP App Store and ‘Platform as a Service’ (PaaS) through Edge there is a lot going on in the clouds over Waldorf.

So, what is ePrint? Well according to HP it offers:

1. Printing from any email device to a printer through HP’s print platform
2. Storage of documents in a secure location within the cloud, which can be printed when required
3. Interaction with Google Cloud Print (to enable printing from Google Documents)

Coming back to how this service benefitted my friend, he is the owner of a chain of Examination Centres in India. To give some background, when candidates are scheduled to take exams (such as GMAT, GRE, etc.) they need to visit an examination centre to write them. Not all exams are based on computer platforms; some are paper based. And, not to forget that some exams are seasonal i.e. they only happen at a particular time of the year.

Before using Cloud Computing, a delivery of question papers had to be arranged to the examination centre around the time of the exam. Clearly this process involved a few costs – transportation costs, arranging security of the vehicle carrying the papers and so on. But now, with ePrint, HP has created an opportunity for Universities to upload (or ‘push’) question papers into the cloud before the exam. On the day of the exam, every examination centre in India prints by pulling this paper from the cloud or alternatively, a centralised system manages the print to all registered printers across all examination centres. As with most Cloud vendors, I believe HP also charges on a usage basis – so while there is a cost involved, it is less than the previous delivery model. The new process is also much simpler and involves fewer parties when compared to the number of parties involved in the packaging of papers, transportation and final delivery.

I personally think it is fantastic that such a simple function such as printing a document can be taken to the “cloud” and benefit enterprises like the one described above.

Assuming HP’s main line of business is print, and we make an analogy with the SAP ecosystem, the opportunities are immense. SAP Consultants deal with all sizes of enterprises across the world and similar to the print business, we cater to most of the verticals. I am sure that in time to come all of us will be looking at more and more off-the-shelf SAP Cloud Services which can provide immense benefits to our clients.

The Challenge: Mission Critical Apps

Mission critical apps inherit their name from the nature of the business process they mobilise. These are apps which cannot afford to leave their users in the dark when there is no connection available. Therefore these apps are built to interact directly with enterprise data stored locally on the device.

The Solution: Cache Synchronization Apps

The Sybase Unwired Platform supports mission critical applications by equipping developers with a client application programming interface (API) and server components to enable synchronisation of enterprise data between the device and the backend. Traditionally synchronization logic can account for up to 60% of the development effort if it were to be built from scratch. Therefore from a development point of view, a complexity-alleviating tool like SUP allows developers to focus on delivering mobile apps that offer great user experience and sound business process in a relatively rapid time frame.

The Challenge: Hybrid Apps

Hybrid apps inherit their name from their ability to merge the instant value proposition of Web technologies (like HTML, CSS and JavaScript) with native device services such as GPS, telephone and notifications.

The Solution: Hybrid Web Container

The Sybase Unwired Platform supports hybrid applications through the Hybrid Web Container and typically serves apps with low data volumes, simple user interfaces, no long lasting offline transactions and basic business logic.
The Hybrid Web Container is a native application with an embedded browser. It is an application in its own right, built by Sybase in iOS, Android, Windows Mobile and BlackBerry flavours. Its Web browser  capability allows the Hybrid Web Container to exploit the power of Web standards such as HTML/CSS and JavaScript to enable Web developers to apply skills they already have to build mobile apps that support the following use cases:

• Lookup – Allows mobile users to request information from the enterprise backend by invoking a simple request/reply or lookup.
• Workflow - Mobile workflow enablement where the mobile user needs to take action or make a decision to move a transaction along the business process.
• Notification – some event takes place in the backend resulting in the mobile user being notified with information.

More about the Platform

Middleware

Both mission critical and hybrid mobile applications require some kind of integration middleware to coordinate the various push notifications and data synchronisation mechanisms across multiple device subscriptions. The Sybase Unwired Platform provides developers with a set of tools and components to design both cache synchronisation apps and Hybrid Web Container apps through a single integrated development environment known as the Sybase Unwired Workspace. Mobile applications are modelled using the SUP modelling concept called Mobile Business Object (MBO). Once defined, mobile applications are then deployed to the Sybase Unwired Server. This middleware component provides consolidation of enterprise data from heterogeneous backends and out to a heterogeneous pool of mobile devices.

The MBO Concept

A concept known as Mobile Business Objects (MBO) modelling allows different data provisioning sources such as Web Services, JDBC and JCo connections to be bound to an abstract business object known as an MBO. Amongst other things MBOs describe how data is to be loaded from the backend and how data is to be synchronised out to a device (for cache synchronisation apps that is). Relationships can be defined between MBOs in what is effectively the data model for a mobile application – similar to an entity relationship diagram.