Thinkervine

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.

Lately, I have been highly involved in the implementation of SAP Business Planning and Consolidation for NetWeaver at a customer. As you might know (or not), this product was until, this morning, in a Ramp Up process.

This is the first version of the port of the Oulooksoft product on the NetWeaver platform, it has introduced along, several new concepts to the solution, which are basics of a standard SAP solution.

Among the changes, SAP BPC for NW has now the transport concept which allows you to transport your customizing along the environments on your maintenance track. As the product lacked documentation on this aspect, I have decided to release a document providing an overview of the transport concepts, tools and a governance approach for managing changes in SAP BPC.

You may download the white paper from the SAP Developer Network, on the Enterprise Performance Management page.

The Sun acquisition by Oracle has been a long debate on the press and Twitter.

Yesterday, as I was strolling through our internal corporate portal, I saw a headline post about this topic which continued in our internal forum, asking about our thoughts on this move. I thought I’d just share them with everyone.

First, we have yet to spot the real motivation that lead Oracle to overtake on Sun. Might be end-to-end data center solution or can be software based (Java mainly).

If you look at Oracle’s portfolio, it is mainly Java based, wether it is Oracle Database design tools, Middleware or most other applications. So, leveraging Java technology will certainly be a big asset for them.

Sun and Oracle have both a whole different corporate culture and outlook on open-source. So far Oracle has only done limited Open Source incursions. Mainly their Linux support service was a way to draw in more database customers. Oracle has a different approach to open-ness than Sun has. Plus the open source business model relies on services which is not something Oracle is really experienced with as they mostly rely on partners. And since Sun has drastically reduced the open source service over the year, they might not prove better monetizing these solutions.

The Java community is among the most importants in the IT world, Oracle cannot take back some of asserted concepts, like open source, availability/portability and roadmap for Java and its SDK. But they could fork their development into a community version and an enterprise version, providing a business oriented framework which is the main motivation for enterprises. On the other side, you’ll still have community produced content and software (Struts, Spring, Hibernate…).

Looking through MySQL, there are two differentiating parts:

• MySQL as a community and open source database, which might be kept as en entry database software, that fits well with the web world
• MySQL Enterprise (including MySQL Cluster) which will certainly be cut dead as it is a direct competitor to Oracle.

Although, for cost reasons, Oracle will probably reduce the team sizes for these community products to the minimal requirement. Hence you can expect more delayed releases and less improvement over time. The maintenance will probably an issue to discuss.

Oracle will probably kill all the non profitable side apps like Glassfish, Netbeans as they will try to impose their own existing tools that have been acquired through the years (especially through BEA). Not to forget that Oracle is a member of Eclipse, which is the main Netbeans competitor.

Now on the hardware level, the fact that Oracle provides hardware will probably change its relationship with hardware partners. For example, I can see the HP-Oracle Exadata partnership killed as Oracle will manufacture its own high profile database platforms.

Will the software still be agnostic ? Not sure. You might see in the future a delayed support for other platforms (Windows, AIX, HP-UX, Linux).

One of the main opportunities Oracle gets by acquiring Sun is entering the Cloud Computing world, they would be able provide an end to end platform. Sun has already made great achievements and acquisitions in this way. Completing their infrastructure with Cloud oriented applications (web application servers, database) will certainly reinforce Oracle’s position on this market as a global provider.

Now what are the threats to SAP ? It all depends on how strong the SAP-Oracle relationship in the coopetition environment.

SAP is a main driver to Oracle’s database world so has it been for Sun’s hardware and software (OS, Clustering). On the other hand, Sun was maintaining a specific SDK for SAP in order to run NetWeaver 7.0 Java based platforms. Will the version still be maintained by Oracle ?

As for future releases, SAP has taken a step ahead and is now basing the new solutions on its own JDK, named Solid Rock, this reduces the liability to Sun’s releases thus to Oracle. On the other hand, SAP uses its own framework for building Java applications (CAF and Java webdynpros), thus the impact of Oracle owning Java cannot be significant.

Still this rises the liability to its main competitor for future releases. In order to be kept aligned on future evolutions of the technology, SAP will still have to leverage the advancements made by Oracle on Java in order be standards compliant. Unless Oracle suddenly threats Java as a private and proprietary asset, SAP might not affected by this.

Oracle has now become a big threat to IBM then to HP (and possibly Microsoft) rather than SAP. The position against SAP will barely change by this acquisition, but this makes an important competitor to these 3 others.

La SOA (Service Oriented Architecture) représente depuis quelques années l’un des principaux maux de tête des DSI, des architectes, des éditeurs et des sociétés de conseil. Gartner prévoit que 80% des  projets informatiques seront basés sur la SOA en 2008. Aujourd’hui, 40% des entreprises démarrent des projets dans ce même sens. Cependant, on trouve difficilement une définition communément admise de la SOA.
Je me propose d’être votre guide afin de mieux appréhender cette notion plus ou moins obscure. Nous vulgariserons l’ensemble des concepts au delà des aspects techniques (qui ne seront pas traités dans cet article).

Depuis quelques années, Oracle a acceléré ses acquisitions afin de compléter son offre Business Applications.

SAP has been encouraging its employees about blogging. Two of its main communities (SDN and BPX) even offer a blogging platform in order to allow employees, customers and experts to blog about SAP and its solutions.