What is the definition of an "application"? We are "applications development and delivery professionals" - surely we have this question nailed, don't we? The question keeps coming up in different contexts, and since there are many potential opinions, a blog is the perfect place to spur debate. Here are some (simplistic) questions to generate debate:
Is a Web page an application?
If not, how many Web pages does it take until I consider it an application - 10, 100, 1,000?
Does size matter? (Please behave yourselves with this one.)
Is the size of the code base a pertinent factor?
What about SharePoint sites, Access databases, and spreadsheets? Are they applications?
Where do COTS and packaged apps fit?
Does the technology I use affect the definition?
If I use a scripting language for a quick-and-dirty task, is that an application?
Does SOA erode the definition of an application?
Do we cease thinking about applications as entities and think about them more as containers that hold collections of SOA services?
How does open source affect the definition?
How does my role affect my perception of an application?
Do developers and users use similar definitions?
I have my opinions - in fact I just finished a draft piece of research on it that will be published in January, but what are your opinions?
So you need to formulate an application modernization decision -- what to do with a given application -- how do you begin that decision making process? In the past, modernization decisions were often simply declared -- "We are moving to this technology" -- for a number of reasons, such as, it:
Keeps us current on technology.
Provides a more acceptable user-interface or integration capability.
Increases our exposure to access by external customers.
Increases the volume of business transaction we can process.
Trades custom/bespoke applications for standardized application packages such as ERP, payroll, human resources, etc.
Fast-forward to today -- you could simply go with your gut -- declare a solution based on what you currently know (or think you know) about the application in question. But it's a new day baby -- a proposal like that, without proper justification, is likely to be met with one of two responses from management:
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. ..."
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.