Is Lawson about to reinvent itself? Remember a couple of years ago, how everyone was trying to be part of the offshore phenomenon? Lawson, not wanting to miss the party nor the potential savings, hooked up with offshore services provider Xansa (see http://www.danalytics.com/guru/letter/archive/2004-03.htm). The plan was that Xansa would be utilized, “…to manage Lawson’s product maintenance services…” and to “…increase Lawson’s development capacity, to focus on new product development.” (see http://www.xansa.com/shared/pressreleases/192037).
See, Lawson’s primary competitors have been using offshore resources for some time now. Lawson now has a new CEO, who came from such a competitor, and who is a big believer in using offshore resources for cost containment. Even some of Lawson’s biggest customers are demanding it, and expect Lawson to pass along the cost savings (while this might be true, perhaps, for services, I doubt that Lawson plans to reduce its maintenance fees!) Like it or not, offshoring is here to stay, and Lawson has to play along.
Lawson’s dilemma is now what—exactly—they should be sending offshore. A software company is essentially composed of four functions: development, support, services, and sales & marketing. Of those four pieces, we know one that certainly won’t be sent offshore: sales & marketing. (Wait a minute…that’s an interesting strategy—Lawson as a telemarketing company. Oh, never mind).
Lawson also announced at CUE 2005 that it was putting together a “blended professional services” offering in partnership with Xansa (see http://phx.corporate-ir.net/phoenix.zhtml?c=129966&p=irol-newsArticle&ID=707047). This would allow Lawson to offer cheaper services to its clients, by leveraging Xansa’s offshore resources for consulting services.
Which leaves support and development. I do not think, in Lawson’s case, that these can effectively be broken up—there is a significant amount of interaction between GSC and development. While I may be the atypical example, the majority of my calls end up being resolved by a developer not a support consultant. Nevertheless, let us make the somewhat safe assumption that 30-40% of Lawson’s support calls require some interaction between GSC and development. In addition, remember that Lawson still manages the case workload with their own homegrown application (yes, it is a LID application written in 4GL!). Add to that the time zones and the cultural/language differences, and you will soon understand why having development and support separated across the hemispheres is a disaster in the making!
Therefore, since you cannot effectively offshore one without the other, it means that they both have to go. However, something has to stay in MN to appease the locals, right? Or does it? Perhaps Lawson can split things up by product line or platform? Technology (Environment and IOS) support and development stays in MN and COBOL application development goes offshore? On the other hand, perhaps iSeries and RPG stays and 4GL/COBOL goes?
Then, along comes Landmark.
Landmark changes Lawson’s application development approach. To use an analogy, think about how Visual Basic changed development for Windows applications. Before VB, you needed to know an unapproachable lower-level language (usually C++). You had to write bazillions of lines of code to create a window, put buttons on it, etc. Then along came VB, which is an order of magnitude easier to develop with—you paint your window, call form.show() and you’re done.
Based on what I’ve seen thus far, I’d expect a similar experience with Landmark. You write “design instructions” in Lawson’s pattern language and Landmark spits out a finished Java application. You don’t need to know Java. You just need to know the pattern language, which is far simpler than COBOL. So, while Lawson still needs to maintain and enhance Landmark itself (much like supporting and enhancing the Lawson environment), they simply don’t need all those COBOL programmers anymore—they need analysts (or more formally, subject matter experts) who can write the specifications and the Landmark design instructions. And those RPG programmers? Lawson won’t need them anymore either.
Which highlights the dilemma: Should Lawson send the remaining “legacy” COBOL/RPG development and support offshore, and keep Landmark in MN? This means a huge ramp-up for Xansa on the old-style Lawson applications (and judging from some of the questions I get from India, they still haven’t even figured out the basics of Lawson). By the time the Xansa folks learned Lawson well enough to be effective, the clients would all be migrated to Landmark.
Or, should Lawson keep the COBOL/RPG stuff in MN and offshore development of Landmark applications? Well, that will alienate Lawson’s own developers, who can’t wait to get their hands on Landmark. And many of those developer positions can be eliminated. No longer do you theoretically need 40 COBOL programmers to maintain AP. Now you just need a handful of analysts.
This brings me back to where I think this will ultimately lead. I would expect—and it’s pure speculation on my part—that Lawson will keep the COBOL/RPG development in MN, and as that development dries up, turn some of their better developers into Landmark analysts, but ultimately eliminate a lot of those positions. And, I’d expect that, for the foreseeable future, the bulk of Landmark-based development will be done offshore.
What I see is that they are about to structure themselves into two parts: an “application enablement” organization (based in MN) which builds the tools (IOS, Landmark, etc.) and the traditional “business application development” organization (based in India, with direction and specifications coming from St. Paul), which does the application development (i.e. the old COBOL work, which will now be done in Landmark). Think of the Microsoft model–operating system, tools (SQL Server, Visual Studio, etc.), Office, and business applications. Lawson will keep Landmark itself and what remains of the Lawson “technology stack”—Lawson’s crown jewels—in St. Paul. The rest will go—support and development. And, remember that assuming the Intentia merger comes to fruition, Sweden is closer to India than St. Paul!