1. , ,
1.1
- , , .
() , , ( ) , ( ).
1.2
,
 | |||
 |
| / | ||||
| , , | ||||
| .. | ||||
| .. | ||||
| .. | ||||
| .. | ||||
| .. | ||||
| .. | ||||
| .. | ||||
| .. | ||||
| .. | ||||
| .. | ||||
| .. | ||||
| .. | ||||
| .. | ||||
| .. | ||||
2.1
Integration: What does it really mean?
( Times New Roman,12)
Why do so many application integration projects fail? Some get bogged down in trying to overcome technical difficulties in the systems undergoing integration; others try unsuccessfully to adapt business processes and/or data across systems before the systems are equipped to handle the changes. In such cases, the business value of the project -- in terms of either time-to-result, quality of result, or return on investment then becomes questionable. In fact, the failure rate for such projects is so high that typically, even many years after a merger takes place, the original companies' software support systems remain uninterested. With the pace of mergers and acquisitions today, this situation is simply not acceptable in terms of both cost and business efficiency. Application integration projects need to deliver business value quickly by enabling superior, autonomous business processes -- that is, business processes that can stay competitive and adapt in an ever-changing world. For business on demand, this quality becomes critical.
|
|
|
Integration is fundamentally a business problem. The experience of one of our customers, a large global bank, underscores this point. The bank's business strategy is to achieve global growth through acquisitions, and it has become very good at it; over the last six or seven years, it has acquired one or two new banks each quarter. At first, however, the bank's IT people estimated that even the most aggressive systems integration project following an acquisition would require six to twelve months of work. And that would accomplish integration of only the most business-critical systems from the newly acquired bank. Our customer's executives soon realized that IT integration was creating a bottleneck in the bank's growth strategy. And, as you can imagine, the CIO certainly was unhappy about having to tell the business executives that they simply couldn't grow the business as fast as they wanted to. So what did IT do to get around this problem? Well, their solution was very pragmatic. When they acquired another bank, the first thing they did was to make models of the acquired bank's systems. They mapped to the most detailed level whatever customer
Developing enterprise-scale applications today requires an approach to software architecture that helps architects evolve their solutions in flexible ways. This approach should permit reuse of existing efforts in the context of new capabilities that implement business functionality in a timely fashion, even as the target infrastructure itself is evolving. Two important ideas are now considered central to addressing this challenge.
2.2
2.1 - .
2.2 , .
