Agile Computing
Carl Bunje gave a presentation
summarizing what has been concluded in previous reviews of this problem -
business agility and the role of an IT standards framework in
contribution to the solution space for it - and asked what we in The
Open Group membership can and should do to promote interest in
addressing it.
He described what he means by an agile enterprise, and placed this into
the context of The Open Group Boundaryless Information Flow mission. He noted the relevance of taking an architectural approach.
Service Oriented Architecture (SOA) could be one of
the bridges between the customer and supplier sides in the
"agility" space. SOA is a big subject - there are many
different ideas on what SOA is. (The Open Group conference in October
2005, Houston, US will address this topic.) Manageability,
security, and quality of service are key parts of SOA. A shared understanding of SOAs and related service level agreements (SLAs)
is important, particularly when establishing SLAs between business
partners.
"Trust" is a major part of this problem, but it is not an
architectural issue and extremely complex to measure. It is a business
issue, involving the need to define business and legal requirements, and
reconcile both business and legal processes ... the technology component
here is small by comparison. An infrastructure could be evolved for
this, but seeking to agree a common model would be difficult.
What keeps customers from making an "agile" approach a key
component in their IT development strategies? "Agility" is not
a term that registers well with customers, but this doesn't mean they
don't need it - rather we need to find a better way to reach the IT
people who work on it now and cut the time it takes to do. Reducing
costs of IT systems remains the most important business driver in most
organizations, and this is unlikely to change. The key is to show how
investing in IT system agility will result in reduced costs. We must
also include the complexity dimension - closed systems are generally
less expensive and do things in silos, while loosely-coupled systems
tend to be more expensive and require expert technical resources to
configure and maintain.
Agility, cost, performance, and risk are related concerns. In this
area we have no best practices to fall back on. The design patterns
approach to IT problem areas might be used to address the agile
computing space, taking in performance, service delivery, management,
and cost. (There was a design patterns workshop held in Dublin during
the Identity Management session.) Ian Dobson said
he would take the suggestion for applying design patterns to the agility
issue to the Security Forum.
Packaged software makers should be added to customers and suppliers
as another constituency in the agility space. Pre-packaged software
gives economies of standardization and solution space, so we could take
actions to encourage them to do things in ways that facilitate agility.
In this context, we must also keep in mind that to achieve reductions in
cost and complexity, we have to accept some degree of supplier lock-in.
We
should appreciate the position of agile computing in the evolving computing time
cycle. SOA seems to be having its time now. Perhaps agility needs to
wait for its time?
Who are the right people within member organizations we need to
reach, and how should we reach them and engage them in the agility
requirement?
At Shell 15 years ago, the right people in the organization were perhaps
two. Today, the right people are nine in number, each representing their
operational business area of the organization. The same
evolution is likely to apply to most large multinationals. Getting all these people
together to address the agility problem would be difficult, for
logistical as well as priority of importance reasons. Technical people
generally accept too readily the low-cost drivers,
whereas an effective architecture is needed in order to articulate the
options.
We know who the right people are, so our real question
should be why is it not high on their agenda?
- Customers are not making the demand so suppliers are not seeing a
market need to respond.
- Suppliers are not yet convinced of the business benefit of
creating common standards for agile computing.
- People who care are not clear why The Open Group is the right
place to work on the problem.
Most suppliers share a common
vision for "agile" systems so why should there be so little
agreement among suppliers on a common infrastructure, when having a
common infrastructure here would clearly benefit customers? The Open
Group is well-placed to consolidate the customer voice here - customer
members can work together to pull a common framework together. The customer side
must demonstrate that there is a market for this before they can expect
suppliers to respond.
System integrators are a further constituency that
also sees the problems associated with lack of agility in IT systems.
They have a huge range/variety of customers so know most of the problems
that customers need solutions to, and they are a large enough group to
be interested in moves towards creating a common framework.
Should we approach academia to invite contributions for solutions in
the agile space?
How can we engage with the many smaller suppliers - SMEs in Europe,
and SMBs in North America? SMEs represent about 70% of commerce in
Europe, whereas SMBs represent about 30% in North America. The EU and US
governments both have departments dedicated to looking after SMEs/SMBs,
so we could try to work with them. The Open Group will take this up with
its representative in Brussels (Scott Hansen).
It was suggested that the cost of participation in work undertaken by
The Open Group may be a barrier, although they are considered an
important customer group.
Where should we go with this agile computing initiative? Suggestions
included a workshop, a BoF (or series of BoFs), and a working group
sponsored by the Member Councils. A workshop would need to be announced
with a clear set of goals and objectives.
Members can take the messages back to their organizations, and ask
questions such as:
- How can we do something here that gives back real value?
- What activities should we create to make The Open Group the
attractive place of choice to do any work?
- Would getting adaptive and on-demand camps together help to move
this forward?
If we could conquer the complexity issues in this
problem then there is a win-win situation for all affected
constituencies - customers, suppliers, packaged software makers, and
system integrators.
Moving the requirements from generalized statements
into the quantitative domain (e.g., what cost savings does the proposed solution
represent?) will help enormously to raise this higher up the
priority chain. The resulting business proposition would
decide whether it attracts a real sense of urgency.
Improving the Value of Membership
On behalf of the Board, Jim Bell led this item. He gave a summary of
the initiative that the Board took in holding a BoF session in the
previous conference (San Francisco). At the global strategy level, the
Board has agreed a global strategy called Boundaryless Information Flow.
This strategy is well-positioned and highly relevant to today's IT
needs. It has been quite consistent over several years - the integrator
strategy, IT Dialtone, Integrated Information Infrastructure (In3), and
now Boundaryless Information Flow. This relatively consistent high-level
strategy has had a very modest effect on the activities that Forum
members choose to work on. The Board would like to help members in the
Forums to improve this connection so we all appreciate better what
Forums can do to help realize the strategy.
Jim recalled that feedback from members in the San Francisco BoF
included:
- Go after the low-hanging fruit
- Re-establish routine meetings of Forum Chairs to improve awareness
of work in other Forums
- Do more information sharing between Forum members - as part of a
regular education process
He invited suggestions for further ways to promote better
co-operation between Forums to fulfill the Boundaryless Information Flow
mission. Suggestions included:
- An Open Group unified glossary, to establish common understanding
of key terms that tend to have different meanings in different
Forums
- A unified ontology - in which common terms are defined along with
the taxonomy (context) in which that meaning applies
- Assigning to Forum Vice-Chairs responsibility for maintaining
awareness of the work in other Forums - an interoperability linkage
- and reporting to their Forum members on work items ongoing in
other Forums that could be relevant or have an impact on their
Forum's activities; Forum Chairs could then be more available to
cover liaison with the Board and other strategic issues (this would
require Vice-Chairs to recognize what is relevant, as well as what
gaps exist that need filling)
- Forum members should keep asking themselves about work they do
that makes no contribution to Boundaryless Information Flow -
this requires members to validate (i.e., pin down in practical
value/case terms) how the intended deliverable(s) will contribute
tangible value to Boundaryless Information Flow
It may not be readily evident that diverse items of work from various
Forums do in fact amount to a value-add picture that can be drawn
together into a useful contribution to Boundaryless Information Flow. It
was likened to the pieces of a jigsaw puzzle - even if we do not have
all the pieces, we can still create something of the overall picture. We
can then also see where the gaps are. Cross-Forum sharing of this
"jigsaw puzzle" of information about their intended
deliverables could well bring out value-add contributions to the
Boundaryless Information Flow picture.
Forums are not naturally bashful about collaborating where they see
benefit. However, an example of lack of awareness and resultant
duplicated effort was cited - the Architecture Forum work on the
Certified Architect would have been useful to the Messaging Forum
members but only became visible to them when they saw the Company Review
announcement. Shell have a "project excellence" impact
assessment process built into their development process - this mandates
that significant development projects are not funded to proceed beyond
their key milestones ("stage gates") until all affected
business operational areas have formally acknowledged their awareness
and potential impact of that project's deliverable(s) on their business
operations. It was suggested that The Open Group build into its Forums
processes some similar cross-Forum visibility and impact review and
sign-off. It was noted that the 30-minute Forum Reports-Back session
(2/3 slides per Forum) that was a feature of past conferences is not
sufficient to provide the necessary visibility or impact assessment. It
was suggested that this could be delivered to each Forum as a 1-slide
bullet-point list from each of the other Forums.
There are two approaches to handling effective cross-Forum
intercommunications - distributed and centralized. Within the latter we
need both a global architecture and good program management.
