Applications are getting more complex. Older apps, some still mission-critical, in-house built are decades old. ERP emerged when it was realized some functions were not strategic, then CRM appeared. The next step is COTS (component off the shelf), and SaaS (for quicker deployment). In addition there are the power end users (e.g. development with Visual Basic), building critical applications, at times.
The whole landscape mixes these approaches and makes it complex. It also makes the options more difficult to select for a given project.
Trends:
- SaaS is a consideration for enterprises of all types and sizes (example of business people making the move without IT, because they feel incontrol)
- Some offerings are getting sophisticated
- It can "happen" without AD
- The financials are very different (the comparison is difficult between ongoing subscription and upfront payment).
Service orientation is undergoing a major change: the mental barrier between design and runtime must be removed: make the changes "on-the-fly" on services, on BPM... However, for business-IT alignment, overlapping cycles may be great or terribly bad (when thigs go wrong). It is not yet a reality.
The old transaction-centric world was code-driven and IT oriented, highly centralized, rigid and autonomous, focused on the enterprise. Now it goes web centric and global, federated, model driven (with lots of tools to help, to develop with new environment and to evolve from older tools), service oriented, process centric, agile (e.g. Scrumm, used also out of IT). The old world cannot be ignored though.
Development used to be for IT people but it is now accessible for anyone. The end user development is focused on getting things done, involving distributed and uncontrolled people and is not much about programming. The business people will "shop" for services as they do in the supermarket.
The digital natives have new expectations: applications installed as on Facebook, managing process models on PDAs...
The application environment will be mixed and it REQUIRES portfolio management. The architects will be useless without an application portfolio. The portfolios must manage the "parts", procedures and people (not necessarily sophisticated, e.g. wiki).
Methods: it started with "code and fix", then "engineering", RAD (to deliver quickly, although often bad quality) and now model-driven, agile and/or iterative. The latter methods are not new but had been ignored. About 60% of organizations are still in a waterfall approach, but this figure is down from 70-75% in a few years.
The troubles with waterfall are various: they are often hit by the "winds of change", the length it takes to deliver... Short cycles improve predictability and bring agility.
These new methods need the business to be really engaged.
They also require new "agile" project management techniques (practices, measures...).
The mistake is to believe AD is traditional engineering. It is much more empirical engineering.
New roles appear as well: the enterprise architect, the solution architect (who understand what the business needs as well as what is available) are more important, and services architect (with a service oriented mindset)...
Change is constant (and accelerating) but there is resistance. It needs to be thought of. On average, in about 3 or 4 months, all requirements in a project will have been impacted in some way or another. The ALM holds the knowledge, the memory of the IT organization.
From the questions: agile offshoring is close to impossible.
No comments:
Post a Comment