Database Reference
In-Depth Information
Firstly, we would like to place strong affectation on the word consistently, otherwise, all
delivered solutions will tend to be quick and dirty with rocketing operational costs. The
two ways (mentioned previously) don't need to be exactly inversely proportional, and
proper balance can be found, as we will see later.
A shortened delivery cycle simply means that we will strive to employ the existing reus-
able components if feasible. Also, every new component or element of the infrastructure
that we will add to our inventory will be designed, keeping reusability features in mind.
The good rate of return from previous investments (that is, ROI) is the main direction of
implementation for new products. At the same time, a higher level of reuse denotes a
lower number of heterogeneous components and elements in the infrastructure.
A less diverse technical infrastructure with more standardized components tends to be
more predictable and consequently more manageable, and the lowering
Total Cost of
Ownership
(
TCO
), which is the key part of operational costs, becomes more attainable.
With higher ROI and lower TCO, an organization becomes more adaptable to market
changes. This is because with them, we will maintain a more transparent and understand-
able application portfolio with a high level of reuse, and at the same time, reserve more
money for creating new and best-of-breed products in the areas of our business expansion.
How can these strategic business benefits be achieved from a components' development
standpoint? We have already mentioned that to make our components more interoperable,
we should reduce the level of disparity, but at what level? By building components on the
same platforms using the same languages, versions, protocols, and so on? This will be un-
realistic even within a single department, not to mention a decent-sized enterprise. Our de-
velopment and implementation processes must be focused on reducing the integration ef-
forts between components, aiming to standardize interfaces. Taking this standardization
further onto higher levels, we could achieve a certain abstraction level that will be com-
prehensible to business analysts yet present enough technical details to be sufficient for IT
personnel. The long time benefits promised (which may not be entirely directed) by
object-oriented programming
(
OOP
) are quite rarely achieved due to the complexity of
inheritance and encapsulation concepts.
The
Agile
developing approach is the solid basis on which business analysts and technical
leads can find mutual areas for fostering reusable components with minimal interaction
cycles. Still, the Agile methodology in place is not the main prerequisite for achieving
this, and if correctly maintained, the level of interface abstraction allows people from both
business and technology fields to speak the same language. The main outcome of this ex-
ercise should be to provide a description of a component's interface with business-related
Search WWH ::
Custom Search