Je vous en souhaite une bonne lecture.

The values are multiple:  smooth integration of the software and the hardware in order to enhance the processing of information. The first applications were naturally in the Business Intelligence field, where executives and operatives always looked for up-to-date, nearly realtime, information on various areas.

But HANA could also have several applications in other fields. SAP is looking forward into using this technology for other fields, and I can foresee a great usage in several areas:

- EH&S: Calculations of the characteristics of products in order to determine the product safety and identify the dangerous goods. Identify the compliance to the various agency regulations. This could also be applied to other initiatives such as REACH.

- Supply Chain: Optimization of automatic packing, route optimization for transport management, planning.

- MRP: We all know how much this is a consuming and lenghty process, which obviously, should make great benefit from the HANA technology.

- Finance: Period closings should be significantly optimized and reduced.

These are a few examples of where HANA could help ERP systems make more from In-memory technology, and would definitely be life changing in several areas, allowing companies to gain a competitive advantage (gaining in service levels).

SAP, just like many other vendors, embraced these paradigms, making its software comply with the customers expectations, and providing solutions that support the concepts of agile provisionning.

Through a comprehensive toolset, including PI – CE – ACC, SAP has provided a solid base to shift from monolithic and siloed applications to open composite apps, based on service components provided using different technologies.

Once we provided enough agility to the application, we were due to align on the infrastructure. Cloud computing allowed to design the next generation architecture. Although, let’s face to face it. Neither SOA nor the principles of cloud computing are new. They have been around since two decades already. But technologies (hardware and software) have matured to the level of providing mainstream solutions that can be leveraged for these purposes.

As such, we have seen several great products shaping including ones such as Business By Design or Amazon’s EC2.

Now, we’re 2010, and we’re just at the starters of a technology downturn. From an usage standpoint, there have been  massive changes to the world of business applications. SOA and Cloud Computing have offered a first level of transition supporting these usages:

• Mobile access including the usage of embedded devices in a smartphone (camera, GPS)
• Mobility: applications available anytime and anywhere
• User Experience focus (UI, desktop personalization and virtualization)
• Increasing real time requirements

And we’re still about to see several newly emerging trends.

If you’ve attended TechEd this year, you might have heard of a few of them. Tighter integration between the hardware and the software: HANA appliances provide high performance platforms for analytics. But this is just the beginning, OLTP systems and middleware platforms are on their way. This also means, that we’re moving back from grid architectures back to heavy frames integrating all components (Servers, Storage and Network). Oracle and Terradata are developing similar appliances.

This has a significant impact where your appliance is designed for a specific usage. This, theoretically, goes against the fundamentals of reusability that are pertaining to cloud architectures. But this is not a bad thing.

The future of architecture will be driven by service levels.

Up to now, SLAs have focused on two main drivers:

• Availability
• Performance

In the (near) future, SLAs will define class of applications and its underlying infrastructure, allowing different visions for each component of the landscape, allowing a better optimization ofthe resources leveraging appliances, cloud computing and virtualization.

]]> http://www.thinkervine.com/blog/2010/11/13/the-future-of-sap-environments-architecture/feed/ 0 http://www.thinkervine.com/blog/2010/11/13/impressions-after-the-sap-teched-2010-demo-jam-in-berlin/ http://www.thinkervine.com/blog/2010/11/13/impressions-after-the-sap-teched-2010-demo-jam-in-berlin/#comments Sat, 13 Nov 2010 21:13:04 +0000 Fays http://www.thinkervine.com/blog/?p=721 This video has been shot by Martin Gillet (@mgillet) right after the demo jam during the SAP TechEd in Berlin. Enjoy the bits.

Photo: Courtesy of Sterling Ely (DogFromSpace @ Flickr)

Besides the innovation brought to the SAP world with Mobility and RIAs over the 2009 – 2011 period, another major trend for this trinity is upgrades.

Fact: 4.6C is running out of support soon and many customers cannot delay it anymore.

They will have to upgrade and for manydo Unicode conversion. While many have already taken a step ahead, many are still waiting to find the right opportunity to leap.

One (of the many) major constraint for refraining the customers to upgrade is the usual associated downtime. An upgrade might result in several hours up to a couple of days of downtime. Although, CU&UC (Combined Upgrade and Unicode Conversion) helped a lot to reduce it significantly, for many businesses this is not something they can afford.

SAP has been listening, digging into the customer constraints and leverages in order to come up with a solution to reduce the downtime. As part of their ALM solutions and services, they now propose the Minimized Downtime Strategy to support the upgrade project (note:this is not the downtime minimized strategy used by sapup).

The Minimized Downtime Strategy comes as a set of  best practices to optimize the leverage of your environment (ERP, Database, Storage and other infrastructure) in order to significantly reduce the downtime linked to your upgrade; Note that this also applies to Support Packages and Enhancement Packages.

Two solutions are proposed, depending on youruse case:

• Incremental Migration and Incremental Conversion (IMIG and ICNV)
• Near Zero Downtime (NZDT)

The Incremental Migration and Incremental Conversion work pretty much the same. It will consist in identifying thelargest or longest running tables in the system, and copy these. You will then perform your migration/conversion while the source system is up and running. Meanwhile,you will copy the delta information using RFC.

Once you are done with these major tables, youenter the downtime phase during which you finalize the delta transfer of the remaining transactions on the source system and copy the rest of the tables which were not copied.

This method relies mainly on an exhaustive analysis phase prior to the migration, during which you identify the tables that need to be transferred and on which you will then activate the proper trigger for data transfer. It is then a matter of planning besides regular MIG/CNV operations.

The Near Zero Downtime Strategy is a bit more complex but relies on the same concepts. Here below are the high level steps:

• Prior to the upgrade, an analysis needs to be carried in order to identify which tables need to be frozen, those for which we will allow updates and for which we need to activate the triggers
• The source system is cloned to a similar system. The target system is isolated from source but for specific data flows
• Users continue working on the source system. Recording of transaction data is activated for all relevant tables into logging tables on this system
• Upgrade is performed on the target system
• Delta transaction data is transferred from source to target during the uptime
• Source system is frozen as we enter into the downtime phase and remaining delta replay is performed, last transports imported
• The infrastructure switch is executed in order to set the target system as the new productive system
• System is validated and reopened to the users

The Minimized Downtime Strategy comes with both pros and cons. You have to face a risk of performance degradation during the delta recording and transfer, and you will have to handle conflicts during the transfer. But on the other side, most activities are performed online. Thus even though, the available business functions are restricted, this does not result into a complete freeze of the business activity. Through a dual landscape, you are also able to leverage more contingency in case of issues, and are still able to reverse to the source system in case of problem during the cutover.

Besides the Minimized Downtime Strategy, SAP has released several other tools to support your upgrade project along the whole lifecycle from the gap analysis up to the final testing. These tools aim to furtherly prepare your operations in order to mitigate the risks during the upgrade and make sure you fit within the downtime window negociated with the business.

I invite you to watch the Virtual TechEd Session presenting the support tools for the upgrade, among which an overview on MDS: http://bit.ly/d378ne.

A tourist walked into a pet shop and was looking at the animals on display.

While he was there another customer walked in and said to the shopkeeper, ”I’ll have that monkey please”. The shopkeeper nodded, went over to a cage at the side of the shop, and took out a monkey. He fit a collar and leash and handed it to the customer, saying, ”That’ll be $5000”. The customer paid and walked out with his monkey.

Startled, the tourist went over to the shopkeeper and said, ”That was a very expensive monkey. Most of them are only a few hundred dollars. Why did he cost SO much?” The shopkeeper answered, ”Ah, that monkey can program in ‘C’ very fast, tight code, no bugs, well worth the money.”

The tourist looked at the monkey in another cage. ”That one’s even more expensive – $10,000! What does he do?” ”Oh, that one’s a C++ monkey; he can manage object-oriented programming, Visual C++, even some Java. All the really useful stuff,” said the shopkeeper.

The tourist looked around for a little longer and saw a third monkey in a cage of his own. The price tag around his neck read $50,000. He gasped to the shopkeeper, ”That one costs more than all the others put together! What on earth does he do?” The shopkeeper shrugged and said, ”Well, to tell you the truth, I haven’t actually seen him do anything, but he says he’s a SAP consultant.”

During the last few months, on a recurrent fashion basis, there has been a topic surfacing every now and then as it hurts our business: planned downtimes.

This said, all global companies, working round the clock, with a presence on all continents, all working on a single global system/infrastructure will face the same problem.

So how do you manage the planned maintenances which, obviously, will impact the daily activities of your workmates, as they do not understand why, in 2010, you still have to stop the systems to carry a maintenance.

Even today, IT/IS is seen as a cost center, barely, as a profit center. In this case, this becomes even more true as it impacts the productivity of the enterprise. Still you need to ensure the consistency of your systems, of your data, do some housekeeping in order to ensure proper performance and sometimes you’ll even have to apply some patches.

So, in the complex landscape that are so typical to the SAP world, how would you manage a proper lifecycle management of your applications and infrastructure without disturbing the business ?

1. Communication

People are able to organize their activities around a downtime, provided they know when it will happen, with enough lead time. A month in advance would be barely enough to allow the proper organization of everyone around the globe. You have to take into account that this might not just affect your colleagues but also all your business partners (customers and suppliers).

You should look forward to publishing a quarterly/yearly calendar with all major activities. Make it online, accessible to everyone so anyone, who has doubts about the planning, can refer to it.

You may also use some marketing and explain how the major operations (e.g: upgrades, support packages) will benefit to their activities.

During the maintenance, you may provide a status to the users to let them know which applications are available. Social Media has great tools for that (blogs, micro-blogging, status pages).

And in order to avoid anyone forgetting there’s a downtime next week, do not hesitate to send a friendly reminder a month and/or a week before.

For all your communications, you will need to target the right audience and have your direct network transmit the information to their teams.

2. Process

Efficient management of planned maintenances is barely a question of technology. Of course it helps, and we will discuss it later, but it only comes as a support.

In order to enhance your maintenances and minimize their length, have a detailed plan of the activities, ensuring that all the dependencies are fulfilled, and that the required skills are available.

After the downtime, review the activities and draft your lessons learned: What should be avoided next time. Use this in your plans for the future.

Periodically, review the last months maintenances. Review the planning and see what can be improved: bundling the activities differently, testing more carefully some items in the test environments before applying them into your production. Among the tasks that have been planned, see which could be planned online with limited impact on the systems/users.

Make sure you manage core and sensitive components differently from the others. While a longer downtime of your intranet might be acceptable, it would harldy be the case of your ERP system. In order to manage this, for each task and system you need to define the criticity and the priority. You will end up building a matrix defining what should be done first and what can be postponed.

Define a rollback plan. Worst thing is to be taken aback. For each task, make sure you identify the risks and your rollback plan. The latter should be planned the same way you would do for any other task (priority, duration, dependencies, resources).

3. Technology

Technology can help you lots in limiting the impact of your maintenance on your business, and you should leverage it.

High availability will be one of your toys to pet. Make use of it. You have invested lots for your DRP plan. But HA can help you otherwise. If you need to carry a maintenance on your hardware for example, you might just switch to your mirror infrastructure and bring the applications back there while you’re working on your primary site.

This is also a good opportunity to test your HA infrastructure and potentially your DRP process.

Virtualization has matured over the years and is now able to provide a high degree of flexibility.It creates a greater abstraction between the different layers. Adaptive computing lets you rebalance your resources between components. As a preparation task for your maintenance, you might look forward making temporary changes in your configuration to avoid a complete disruption of the service. Keep in mind that these changes (and reverting them) need to be supported by a detailed documentation.

Monitoring: Planned downtimes are great but they need to be supported by a rationale which will help you define which activities need to be planned. A proactive monitoring of your systems should allow you not only to get the proper alerts but also to identify the trends and thus identify the key actions that need to be undertaken.

Planned maintenance could easily shift from a pure technical topic into a political one whenever it has an impact on the business. IT, in its state of art, is designed to service the business. Thus, make use of creativity and fine analysis in order to provide the best of breed service to your customers.

Thinkervine is glad to offer to those who wish Google Wave invites.

By now, these have been rolled out to pretty much most of you, but if some still don’t have one, feel free to leave a comment to request one (make sure to input your Gmail account in the e-mail field).

26 invites are available.

If you don’t know what Google Wave is, check out the videos below:

SAP Research developed an application, named Gravity, leveraging the Google Wave collaboration capabilities for Business Process Management, check the demo here:

Most business application consultants and experts have a high emphasis in one aspect of the solution (say finance, controlling, HR, CRM), sometimes, they even go to higher focus (marketing campaigns within the CRM) but very few of them would know what happens in the next phase of the process. They usually work in a blackbox mode knowing the input they’re getting from previous phase, how to process it before serving it to the next phase.

This has worked pretty well due to the widely spread practices in the implementation of processes within monolithic solutions. These processes were also mostly fixed as companies rarely looked forward constant process innovation to keep up with the pace of competitivity. But today, the world’s changing. Processes are being executed across the solution boundaries and even across the company’s boundaries, they may be re-engineered at several phases to match the company’s strategy on the market.

If we take the computer manufacturing industry, the usual process would be “Manufacture the equipment -> ship to dealers -> Select the equipment (customer) -> Pay (customer)“. DELL has drastically changed this process, which earned them a highly competitive advantage at several levels. The process has been changed to “Select the equipment -> Pay -> Manufacture the equipment -> Ship to customer“. At this point, DELL has improved at least on two main points: exit the dealers, reducing the number of  intermediates and they don’t need fully manufactured stocked equipment. Basically computers are stocked in warehouses in a pre-assembled state. Assembling might even be transfered (outsourced) to Supply Chain providers. At this point, they’re having a direct contact with the customer, tightening the relationship, and they’re increasing their profitability (fixed costs reduction).

For solution experts, this has a major impact on the way they usually implement the process. They need to have a complete understanding of the impacts of the re-engineering on their blueprint. How they shift from a data receiver from process step 3 to a data source for step 2.

For this purpose, the experts will require to have a broader knowledge of what they are implementing, how’s their part is being integrated within a wider scope, what happens in every phase and then they should shift into a full understanding of the process end-to-end.

So if you wonder how you can update your skills ? What you should look at ?

I say, forget modules and go end-to-end process: Order to Cash or Procure to Pay. With today’s technology and solution maturity, processes tend to have tighter integration between them. They are not just merely tables and transactions, but there’s a real logic flow orchestrating each step of the process.

Coupled with the Business Process Experts/Champions/Owners, the consultants will seek into bringing a higher value to their customer/company by optimizing the execution of the process at every step with a coherent and comprehensive understanding of the impacts of each action and decision.

In an SOA approach, the isomorphism between the process and the services will lead  to create fine grained components which are then assembled altogether into composite applications. This leads to a tighter integration of components (logical point of view) as a service might as well execute operations in a project and finance systems.

While there might still be confusion among SAP practitioners on the ability to go from a modular perspective to the end-to-end perspective, this change will be driven by the market evolution and the solution architecture anyways. The idea is that rather than being an expert on 10 FI processes while you usually implement 4 of them. The skills evolution roadmap would guide you through the different stages of your process implementation within the other modules/solutions, hence fully leveraging your training and expertise on all areas.

This full fledged knowledge of the process will also provide a new empowerment that will allow experts to drive the innovation to reflect the business requirements or even anticipate them,  as this is where the real value lies.

With the advent of Web 2.0, web applications, thin applications and Software as a Service have lead to a fast development of Rich Internet Applications, in particular the user interface (UI) and usability. Whether they are based on AJAX, Flex or Silverlight, they all have a common purpose: provide an improved user experience through a thin client, at least comparable to fat client’s if no better.

Along the years, many software providers looked forward porting their current business applications to web based platforms, mainly for easing the maintenance, avoiding client deployment. These platforms, mainly based on J2EE technologies, were mostly made of static display, although the content was generated dynamically. On the usability level, users have gone from bad to worse. We all know business software has never been sexy. In addition to that, people now had to deal with constant refresh of pages for every action, increased wait-time while data was submitted to the server, as HTTP is not an optimized protocol for transactional applications.

On the other side, developers had to deal with issues like supporting several platforms (combination of browser/OS), new security aspects on uncontrolled layers, harder user acceptance.

The transition from fat client to thin client has merely been a mess for most software vendors. Reason ? This transition has been mainly technical and product managers have forgotten the main brick: the users.

Any change must under-go a global user acceptance. Especially when it comes to business software, that’s something people will use constantly on a daily basis for their work, you need to make sure to have a wide adoption and make it mainstream. For this purpose, the change must be user-centric.

RIA have the advantage of being naturally user focused. They tend to improve the user experience, allowing a more interactive approach with the web application, unlike HTML.

To the users, RIA comes with its own set of benefits:

• Increase productivity
• Enable an engaging, interactive user experience without page reloads or refreshes
• Provide real-time data management
• Allow users to interactively visualize and manipulate complex data more effectively and easily (drill-down, drag and drop…)
• Assisted inputs (interactive search, predictive typing…)
• Optimized screen layout (reduction of complexity)
• Keep pace with the users expectations. The UI for their business software are now aligned with those of their daily personal apps (E-Mail, Social Networks, Document sharing…)

On the other side, by creating a custom rich front-end, developers can  have a better enablement of the process centric aspect of the application. This becomes even more important when the process goes above a simple application boundaries to be executed onto several platforms.  Screen flows can be designed and organized according to the business process requirements while providing a uniform UI for all the process steps. Screens can be drastically reduced by automating the values of some fields and make them transparent to the users.

With RIA, companies are now able to address most of the users current issues with business software which are mainly:

• It is very complex
• It looks like crap

Through rewrapping their main processes into RIA, companies might increase their user productivity through this mix of process centric (screen flow) and user centric (usability) interface. Some software vendors now tend to understand that and are extending their frameworks to support new technologies that would allow them to enable this into their portals and mashups  (SAP has introduced the support of AJAX and Flash islands).

But just above the technical aspects of the technology, the complete product/project management chain must be educated on the value of these new user interfaces.