Database Reference
In-Depth Information
sponse time to the new challenges will be lowered as the change in the implementation's
task force will be business-driven and IT will be resource-oriented at the same time.
Components, especially developed with a business recomposition option in mind, will
gradually form some kind of components library. With strong sponsorship from architects,
this library will become attractive for more and more extensive reuse in various business
domains, depending on the business context of the components of course. This library has
a name. Traditionally, it's called
repository
, and we will spend a lot of time discussing its
purpose and architecture a bit further. However, from the characteristics standpoint, let's
depict it as a technical platform that is capable of hosting these components and providing
runtime and design-time visibility, which will be discussed further. Simplistically, this will
be any application server with a management console, available for all enterprise deve-
lopers and architects; it will present all reusable components as the sole
enterprise-cent-
ric assets
.
This second characteristic would be possible only when the presented components are de-
signed with the highest level of composability in mind. This means that when integration
efforts, including regression test requirements, platform performance enforcements, and
activity monitoring are tamed enough to a level where the reusability option becomes so
attractive for all the technical and business teams, the idea of reinventing the wheel would
never come as a plausible option. Surely, these characteristics could have more gov-
ernance efforts in the background than purely technical ones. Still, with proper planning
based on honest and realistic maturity assessment and with evasion of the big bang's "all-
or-nothing" approach, when SOA becomes more religion than the practical "one step at
the time" approach, it's quite achievable.
Components developed as reusable assets should follow commonly accepted standards;
otherwise, reusability will be severely limited to one technology domain. Another altern-
ative would be to reinvent the already existing standards, which is always a waste of time.
It doesn't mean that any published standard must be followed blindly; the adoption of
standards must be carefully planned. An enterprise's maturity analysis combined with
marketing research on top products in a particular area will guide an architect towards
common models, describing the component's behavior and implementation technique with
minimal integration efforts. Thus, by achieving the first three characteristics, we will open
the highly desirable option of maintaining the hot-pluggable infrastructure where best-of-
breed products from various vendors could be combined into well-turned fabric based on
common standards. It is an architect's responsibility to stay watchful, analyze standards'
specifications, and deduct the crucial parts and to be focused on increasing the desirable
characteristics.
Search WWH ::
Custom Search