In a conversation with a vendor in the application portfolio management space the other day, we got on the subject of what "Cloud" means to them and by extension to their current and future customer base. My colleagues have written extensively on what it may mean to Oracle, Microsoft, IBM, HP and others, and our conversation began discussing the potential of cloud-computing from a vendor perspective - for instance:
Jean-Jacques Rousseau wrote, man is born free and is everywhere in chains. So too Enterprise app deployments are conceived as self contained yet everywhere are integrated with legacy and complementary apps.
My colleague Ken Vollmer and I are looking at packaged apps integration best practices and how these might change as some apps move to the cloud. We are asking:
What kind of middleware do you use?
How do you help process owners to assemble (composite) processes that have transactional integrity?
What do you do about the conflicting data models of apps from different stables – for example yours and those of a third party or perhaps in –house?
How far can so called “canonical” data models and meta data help to overcome such problems?
If you have experience and an opinion about what constitute the top three best practices in such packaged apps integration, or if you can warn about the three most egregious pitfalls to avoid we would love to talk with you.
OK, so the holidays are over, you've either closed, or are in the process of closing out 2009 year-end processing. The 2010 decade has begun, and it promises momentous change before we see the end of it: Leading edge technologies will become commonplace; Still newer technologies will emerge; New business threats and opportunities will arise; And the impact of the Baby Boomer phenomenon will finally arrive.
OK, so I used a tongue-in-cheek title to attract your attention, forgive me. A recent blog about the Boomer retirement phenomenon provoked some comments by a colleague with strong opinions about COBOL's useful life. I felt that his comments raised a topic that is substantial enough to warrant its own place in the blogosphere. The comments read, in part:
" I am a boomer myself ... But as a software architect who has to look ahead and figure out what customers and users want I can't wait for the 3270 green screen boomer generation to retire. It will allow for the acceptance of a new application paradigm. Those stepping up to the plate will not hesite to dump the COBOL garbage and use modern tools to create modern mobile apps that will finally end the drama of IT as today's business disabler. ..."
The rock-band R.E.M. sang a song about the "end of the world as we know it" and to hear some people talk - the end is near!
The Chicken-littles of the world would have us believe that retiring Baby Boomers will wreak untold havoc. Half the world's population will suddenly disappear from the workforce - collapsing world markets, straining national pension systems to the breaking point, and burdening younger generations with unmanageable national debt.
Other folks are at the opposite end of the spectrum - they're in denial, like ostriches with their heads deep in the sand - if they don't look at how bad the problem is, it can't hurt them, right? No staffing problems here - look we can still hire people, let's deal with today's problems and not go looking for tomorrow's troubles!
I've written a lot of research around the topic of application portfolio management (APM), and how the tools are slowly maturing from their application mining roots. Although the process of APM applies equally across packaged and custom-appls, the mining tools, until recently anyway, have excluded packaged applications.
Our application development team recently expanded with some new colleagues, and one of the topics a new colleague - George Lawrie - and I intend to take on as a joint effort is application consolidation across custom and packaged applications.
We'd like to know - how important is this topic to you - what are the nuances of it that keep you awake at night, or is it a non-issue? If it is a non-issue, why? Have you done such a good job of staving off redundant and obsolete technology, or is it someone else's responsibility? Please chime in, we'd love to hear about your application environments.
I had an interesting inquiry with a client that began with this question - "What is the defniition of a legacy application?" Yikes, I thought - this will be one of those long-ranging, rhetorical discussions that - at the end of the day - lacks the kind of decisive answer clients typically seek during inquiries. The client actually had a good reason for wanting an externally published, formal definition - an external entity was attempting to measure the company's risk by quantifying its exposure to "legacy."
There is a lot of noise lately from 2 camps - one swears that the availability of people with mainframe skills is drying up rapidly - they either forecast dire shortages, or note problems hiring for certain positions internally. Most of the trade press articles are firmly in this camp.
Once apon a time ... the definition of an application was easy - firms built accounts payable, general ledger, purchasing, order entry, and other applications to meet the automation needs of the business. The applications were written as monolithic collections of functionality that were dedicated to accomplishing key business functions and had relatively clear boundaries.
However, over the years, technology shifts have resulted in "applications" that don't fit the earlier simplistic definitions. DLLs, Services / SOA, ASPs and Software-as-a-Service (SaaS) all bent the definition of an "application" from its previous form. Looking forward, Cloud computing promises to alter the definition once again.
I heard an interesting comment from an executive at one of the big services firms - that application portfolio management (APM) efforts must begin by mapping business processes for the applications. I really don't agree, but thought it would make an interesting topic to discuss here. Part of the argument stems from how services firms are routinely engaged - to take action against one application or a group of applications to transform, re-engineer business processes, reengineer, refactor or otherwise modernize an application. All are useful activities and techniques, but they are not portfolio management techniques - they are modernization techniques. Modernization and APM live together on a continuum of application activity that includes in order:
Modernization - the actions we can take against an existing application - monitor & maintain, modernize in some way, replace (rewrite/pkg) or retire.