Software Safari - Premium Blog on Application Software

What if.....

What if VCs, SAP, Your Marketing Team, etc. Designed the Stop Sign

I took a call last week from a friend of a friend who is trying to fight off a patent troll who happens to have a really obvious patent on a process that never should have been granted patent status. As ridiculous as that patent is, it did cause me to wonder how some teams have ever gotten anything developed or patented with all of the management stupidity, lawyers, etc. getting in the way.

Today, I ran across this video that asks the question "What if Marketing Designed the Stop Sign?". You could substitute Marketing for your VCs, your favorite software vendor or any other team when you watch this but once you do, you'll see how the group dynamic can ruin a perfectly good idea. This makes you seriously question the wisdom of some crowds.

Enjoy

http://view.break.com/542649

http://view.break.com/542649 - Watch more free videos

After I saw this, I realized why scope creep sinks so many good software projects/products.

Decelerating ByDesign

                          The Caution Behind Business ByDesign

Coming into SAP's Sapphire conference this week, a number of bloggers, tech analysts and Wall Street researchers were looking for answers around recent decisions on SAP's Business ByDesign product line. Business ByDesign is a relatively new offering from SAP and represents a huge investment by SAP in the Software as a Service (SaaS) space. During a recent earnings call, SAP executives indicated a more cautious approach to the continuing rollout of this product line.

After three meetings today with senior SAP executives, there is now more clarity around SAP's recent moves. We spoke with Henning Kagermann (outgoing CEO), Leo Apotheker (incoming CEO) and others. What we learned was:

• The product is not performing to the cost expectations the company had set for it and, as such, was not operating at the level of TCO (total cost of ownership) that the firm needed for it to be a profitable solution. A high TCO is not something investors or Wall Street would appreciate.
• The root cause of the higher than expected TCO was apparently related to two major items. First, the version of NetWeaver (SAP's development and execution software stack) being used by the Business ByDesign solutions is out of date and needs to be updated to version 7.1 once it's completed. When that's accomplished, the solution should run more cost effectively.  Second, the upgrade process (e.g., the upgrade from Version 1.0 to 1.1) turns out to need more automation so that fewer errors are made and human intervention is reduced. Human intervention triggers added costs and introduces potential errors. This creates quality and cost problems.

SAP executives admitted that their new on-demand solution encountered challenges the company had previously never encountered. First, SaaS was an entirely new space. Second, the company couldn't fully 'leverage their 35 year experience' in application software as these customers were not the typical SAP customer and the solution would be used differently than its prior on-premise solutions. One SAP executive said they "thought they knew this market" but that wasn't exactly true. Lastly, their development staff was caught by surprise as the they did not have the same level of control with this product as they have had with other product lines.

Business ByDesign has been an expensive development exercise for SAP. One source indicated some 2000 persons were involved in the creation of the product. While further development efforts are being scaled back, this has more to do with a planned development deceleration and a need to wait for the NetWeaver architecture to be implemented. In creating the product, one executive commented that the company made hundreds or thousands of assumptions (e.g., how quickly customer deals would occur, what response rate is needed for acceptable performance, the targeted TCO, etc.) and some of these assumptions now require a rethink.

Bottom line for Business ByDemand is that:

• sales will continue in six countries: France, US, UK, China, Germany and India but not beyond these for now
• the company will continue to focus its TCO reduction efforts on cutting the cost of hot-patching, hosting, upgrading and on-going operations. Moving their hosting centers to low-cost countries (for a labor arbitrage) is not being considered for now.
• the $149/user cost figure is being held. TCO will be reduced while customer cost will not be increased.
• adjustments by SAP should take 12-18 months to complete

Making Software Projects More Successful

                    The Economist & Software Development

Fellow Enterprise Irregular, Michael Krigsman, writes about project failures in his blog: http://blogs.zdnet.com/projectfailures/. A mainstream publication, The Economist (see: "Software that makes software better", March 8, 2008), recently analyzed the state of software development and reported the following:

• bugs in new code still amount to five per function point (source: Capers Jones)
• 85% of these bugs are removed prior to the software being put into use
• 35% of software projects in 2006 were completed on time and budget (source: Standish Group)
• The number of failed projects declined from 31% to 19%

Another telling statistic was that developers only spend about 30% of their time coding - the rest is spent communicating with other developers. This is why collaboration technology and frequent (i.e., 24/7) communication with offshore development personnel is so critical to project success.

The tone of the piece was optimistic and realistic. Technical advances in the creation and testing of code are making products better; however, the human element in software development means we'll never be rid of bugs or project failures. Projects will remain problematic because:

• company politics will undermine a solid technology idea
• people are uneven in skill sets
• some people are determined to sabotage projects whether they mean to do so consciously or not
• people fail to communicate critical points, issues or decisions with other team members in a timely fashion

Michael will have a never-ending font of material to draw from for his blog. People are the key ingredient for projects and they're also the weakest link. I am pleased, directionally, with the improvements in development technologies but people are the hardest 'problem' of all to solve.

A Tipping Point for Software Vendors/Developers?

Can this be for real?   

 

 

A couple of years ago, I had the opportunity to spend many hours with the head of product development of a major application software company.  This gentleman had a budget of over $450 million (USD) to spend across a relatively small application software product set. Frankly, I walked away from that meeting shaking my head because I couldn't understand how someone could spend so much money and show so little new product development as a result.   

 

When you talk to software executives, the number of people, hours and testing that is required to build and maintain application software is stunning.  Even with the significant advances in development languages, architectural platforms and other productivity gains of the last few decades, software development and maintenance remains very costly. It's also very error prone too. The article cites a National Institute of Standards and Technology statistic stating that software bugs cost the US economy nearly $60 billion annually. Anything that would help this situation should be a godsend -- correct? 

 

When I read the Business 2.0 article, "Software That Writes Itself" (http://money.cnn.com/2007/08/27/technology/intentional_software.biz2/index.htm ), I decided to look into this a bit further.  In that article, Charles Simonyi and his company, Intentional Software, are profiled (www.intentsoft.com ). The article describes Intentional’s major product, Domain Workbench. From the skeletal description in this story, end-users and turn in textual, spreadsheet or flowchart descriptions of what software should do.  An additional capability allows relationships and other rules to be documented. Next, the software takes this information through a code generator which develops the final programming language. 

 

As proof of its success, the CTO of Capgemini describes how Domain Workbench can complete a project in just a couple of months that might have required 250 programmer work-years to develop.   

 

 

There is very little information about Intentional Software on its website even though the company was founded in 2002. While I certainly understand the need to protect one's intellectual property, the lack of validation points on their own website is noticeable. 

If their product is as easy to use as this article suggests, this product alone would be a boon to US GDP for decades.  However, we've heard other technologies promise significant productivity gains in the development of new application software and the reality of their potential often pales in comparison to the hype that surrounded the new products.  This isn't to say that Intentional Software's products will not work as promised but it is to say that convincing large numbers of companies of its capabilities will be difficult given the track record of products that have preceded it in the software marketplace.   

 

Let's examine though the possibility that it is as good as they claim.  If so, then we should see:

• a huge disruption in the amount of application development work conducted offshore
• systems integrators might experience a claw back of custom development work back into their clients.  However, these integrators would also probably face a material drop off in fees billed for custom development work just because of the power and productivity gains such a tool provides.
• IT departments may regain some of their lost stature in the eyes of end-users as this software would aid in the translation of business requirements to technical software development
• application software vendors may find that all of this recent retooling to support new middleware architectures may be in conflict with a more powerful tool such as this.  In one stroke, their product lines may face rapid obsolescence in the marketplace.
• application software vendors would need to dramatically rethink their value proposition.  Why would clients paid them millions of dollars annually to continue to support their inefficient and grossly expensive maintenance requirements.

This could be a technology to watch but then what other choice do we have?

Software joinery at work

Bill Gates calls the gap between personal productivity and business application software the "last mile" in productivity. In this guest blog excerpted from KiteBlue, Jyoti Banerjee assesses if the gap has been bridged.

The use of portable computing, mobile connectivity and the Internet has changed the way we work over the past decade. However, the organisations we work in, with few exceptions, still work in the same way as they used to ten years ago. Business processes may have got automated along the way, but the engagement between person and process has not changed as much as the changes in personal productivity.

This past week Bill Gates focused attention on what he calls the “last mile of productivity" in his keynote at the Convergence 2006 event in Munich, which he describes as the gap between personal productivity software and back-end business systems. In other words, the  gap between people and process.

What is different about Gates’ solution is the breadth of vision employed in bridging this productivity gap. Of course, we are talking about Microsoft - whose record in translating vision into reality can be likened to a patchwork quilt that has a few squares missing - so we need to be careful about assessing when the vision translates into reality. More about timelines later.

Bridging the gap

In computing terms, I have been waiting for the day when we stop going to the software and the software comes to us instead. Gates’ last mile vision is the first step in getting the software to where we are. Let me explain how in three ways.

One, in combining personal productivity (Office 2007), desktop infrastructure (Windows Vista) and ERP/CRM business applications (Microsoft Dynamics) into a single visual and functional grammar, the user is able to take advantage of business software without the complex, proprietary, training-intensive interactions of current and previous examples of business software. I remain unconvinced about the individual worth of Vista and Office 2007, compared to their predecessors. But combine them with Dynamics and the result is much, much stronger.

The user gets role-specific business information delivered to the desktop without needing to access the business applications that create and store that information. Further, the user can interact with and act on that information inside their personal applications, and still engage with integrity with the business processes that are captured in the line-of-business applications. In practice, this means that the sidebar in Vista can be populated with, say, real-time data from the CRM system – the user can interact with the CRM data inside their Office system, without needing to login to the CRM application.

Secondly, the deep integration between Office and Dynamics is extended by online services. Dynamics CRM is already available as a hosted product via Microsoft’s partners. Now Dynamics ERP has been added to the mix. Next year both products will be available as hosted products direct from Microsoft. Interestingly, as the code base is identical to the one used “on-premise,” it should be possible for medium enterprise with multiple locations to mix and match in-house products with hosted services.

(Personal aside cum plea to Microsoft: on-premise is a nothing word – it means zip. At least, not in Europe. Please do not compound the dismembering of the English language by semi-literate geeks by using premise when you mean premises – they sound similar but they mean completely different things.)

Finally, the Dynamics offering is enriched by online services that bring new internet capabilities to users of business applications. For example, Dynamics CRM customers can integrate keyword marketing with Microsoft adCenter into their online marketing campaigns. And Dynamics AX customers can use eBay as an online sales channel, allowing placement of stock items on the auction channel, as well as downloading financial details for sold items.

Visibility
How much of this exists today? That is much harder to answer. We will have a better idea when Windows Vista and Office 2007 release later this month. The last mile of productivity will be bridged more effectively when we can see next year's hosted versions of the CRM and ERP applications, as well as what Microsoft calls Dynamics snaps: mash-ups that combine Dynamics information with Office 2007 and Windows Live internet services.

The technologies discussed here are not exclusive to Microsoft. Others who expose web services APIs in their business applications should also be able to integrate with the desktop and online services. Ultimately, for the user, the most authoritative bridging of the last mile will come when their need for awareness of the business applications that work in the background will slip away to near-zero. This is not a pipedream, as vendors can already start building custom or vertical applications that exploit the deep integration between Vista, Office and Dynamics. The user can concentrate on the custom software and not worry about visibility of the ERP or CRM suites.

Future of SOA

SOA & ERP – Will this Marriage Work?

There exists a pretty fair group of software analysts out there and some are with Merrill Lynch (e.g., Kash Rangan and Raimo Lenschow). Last week, Raimo published a solid, lengthy report examining SAP’s SOA offering. The back half of the report looked at monetization opportunities SAP may reap from its new platform and the front half took a measured look at SOA and the challenges with incorporating it into an ERP product line. This report ( see http://rsch1.ml.com/9093/24013/ds/9_923061.PDF ) is definitely worth a read.

I’d like to expand on Raimo’s paper. Herewith are my thoughts re: ERP vendors and SOA.

The SOA Challenges

1. SOA is a hard sell to CXOs because ERP vendors do such a pitiful job of marketing the value behind it. I received an email from Oracle the other day. The first paragraph stated:

“SOA is generating much excitement among CIOs because of its promise to solve a range of technical and business challenges – namely, the complexity and cost of integrating disparate systems, not to mention modifying them to adapt to changing requirements. Indeed, SOA lowers your interoperability hurdles and helps evolve static systems into modular and flexible components. That means you can focus on supporting your ever-changing business needs, rather than maintaining a cobbled-together computing environment.”

Please take a moment and read this text. I performed a Fog Index score on that paragraph. It came in at an amazing 20. In effect, this text is appropriate for PhD recipients. Its density is so great that few CXOs will read it or comprehend it. 

2. What ERP vendors don’t get is that SOA is a means to a destination and not the destination itself. ERP vendors need to be communicating the value that SOA will deliver and not the ‘power’ of their platform.
3. CXOs have heard the SOA story before. It is the same message that object oriented programming, XML, open source, data integration and other technologies have promised before. It doesn’t matter whether SOA can actually do what other technologies didn’t, what matters is that Peter has cried “WOLF” so many times that no one listens anymore. SOA and platforms lack market credibility with buyers and proof points, lots of proof points, will be needed to convince them that SOA is for real.
4. ERP vendors lack credibility when it comes to having an inexpensive, flexible way to implement software (and change systems post-conversion). There have been some colossal expenditures of capital by Fortune 500 and other firms to implement ERP software. Do you really think that an executive team will get excited at the prospect of another ERP implementation when their previous one took 4-8 years and $400 million to complete? I don’t think so. I may never forget the conversation I had with the CEO of small-medium size firm who spent $4 million on a Great Plains installation. No one is selling him a new ERP solution after that capital expenditure.
5. When breaking up an old ERP solution into the small pieces that a services oriented architecture dictates, the development of the ‘glue’ that connects each small piece to another may be trickier than vendors expect. When older solutions were created, a number of design assumptions were made by developers. Some of these assumptions are explicitly stated in the software code. An interrogation of the millions of “If/then” statements will no doubt lead to an incredible amount of knowledge. However, it’s the unwritten, unstated assumptions that early developers made that no software tool can ascertain.

For example, let’s assume you were designing an Accounts Payable module in 1987. Back then, systems used sub-ledgers and relied on other subsystems to validate many data fields. Additionally, there was an implied workflow in these products (e.g., the purchase order would be created first in the Purchasing module, a subset of information would be passed to the Accounts Payable system and eventually a summary of that data would eventually go to the General Ledger). What was never codified were the logic issues that would not permit a general ledger or accounts payable transaction to originate before the purchase order was created. Would audit or SarbOx issues prevent this? It’s hard to say as SarbOx and non-standard processing were not known, expected or allowed in 1987. How about this example: Older general ledger systems never allowed an unbalanced journal entry to be processed. In all of the general ledger code I’ve seen in my life, no where did anyone document why this isn’t allowed. But, if someone creates a small SOA routine that allows a single accounting balance to be updated, they will be making a potentially egregious mistake.

6. ERP vendors still don’t get what it takes to make SOA really work for their customers and prospects. Sure SOA will make re-configuring solutions easier and, so too, the connection of custom and other solutions to the ERP platform. However, if ERP vendors really understood their customers’ needs, they would: supply optimized process designs; provide benchmarks to help customers determine how efficient or inefficient their processes are; and, create statistical tracking fields/counters in their software to help users see, in real-time, how operationally excellent their firms really are. Every ERP vendor should have a pile of benchmarks from firms like AnswerThink as part of their solution set. No, ERP vendors see this as a form of IP that they don’t want any part of. Their IP is code not meaningful business data, best practices or benchmarks. This is not only a loss for the customers but a very preventable one at that. Vendors that leave this work to integrators are causing ERP solutions to remain more expensive than they need to be and thus not delivering value.
7. Semantic differences between systems will continue to be-devil SOA solutions.  One old client of mine must have had over 100 definitions of ‘customer’. A Fortune 100 client spent close to 3 years rationalizing 3 data elements across all of their divisions and systems. This problem has caused data warehousing and integration problems for years and it will carry over into SOA solutions, too. Few companies bet everything on one ERP solution. These semantic challenges will slow down SOA implementations, add cost and reduce the value proposition delivered.
8. We need to evaluate whether there is anyone left in many data centers to do all of this SOA process tweaking. Much package software support is now performed offshore. Even though vendors will make it easier for companies to make numerous, fast process improvements/changes, who will do it? It won’t be practical to send lots of little enhancement requests half-way around the world. This phenomena is too early to predict but rest assured, the people who used to modify applications domestically are in short-supply today.

The Good News

Not everything is difficult for SOA and ERP. On the positive side:

1.               Vendors like SAP and Oracle will benefit from companies replacing Y2K solutions. These are products bought in the 1990s to mitigate Y2K issues. As these mostly Unix/Client Server solutions age, some companies will want to replace solutions that are either technically obsolete or no longer suitable for future organic growth.

2.               Hardware constraints used to force a lot of functional and technical limitations on software vendors. Memory shortages, limited disk storage, constrained processing windows, high CPU cost, etc. meant that software vendors sub-optimized their offerings over the last few decades. This is why most U.S. developed ERP solutions used subledgers. Processing was broken up into functional groupings, data was summarized and sent to the next module for processing. Software doesn’t need to do this anymore but will the new SOA solutions reflect this? It’s hard to say right now but the signs are promising.

3.               Third parties may develop new SOA sub-modules to work with the new platforms (i.e., NetWeaver, Fusion, etc.). Raimo’s piece has some excellent analysis on this. New, additional solutions should be a good thing for customers but software developers may need to be careful to ensure that the platform provider doesn’t make a copycat solution of their own. If platform vendors do this, expect their add-on ecosystem to suffer.

Comments?

Narcissus Effect

                             I Must Have Hit A Nerve

Every year I attend MR Rangaswami's killer show in Santa Clara. Software 2006 was held just a few weeks ago. While I've made a number of posts to the www.Sandhill.com site, this week Sandhill put a piece of mine on their newsletter and it caused traffic to spike on Services Safari (www.servicessafari.blogs.com) , Software Safari and the TechVentive websites. This morning alone I received emails from a half-dozen software CEOs who felt strongly enough to write me directly. Thankfully, the feedback was positive and very supportive.

The subject of my article was on how traditional application software vendors have had to wear blinders for so long now that they cannot envision new application solutions that are anything more than minor variations on old products. Even with SOA, mashups and other silver bullets, the innovation isn't really there. If you'd like to read the piece, follow this link to Sandhill's site: http://www.sandhill.com/opinion/editorial.php?id=82 . Also, I have a longer version of the piece I you'd like it. Please email me at: brian@techventive.com and I'll send it right out.