3. Achieving efficiency and effectiveness through systems design Editor: Per Flaatten (Retired Accenture Partner) Introduction

Download 64.37 Kb.
Hajmi64.37 Kb.
1   2   3   4   5   6   7   8   9   10   11
Axborot texnologiyalari va ularning turlari, Нутқнинг тўгри бўлиши асосан қайси ме, Нутқнинг тўгри бўлиши асосан қайси ме, Нутқнинг тўгри бўлиши асосан қайси ме, календарли режаси, FIZIKA 10, 7 sinf Tarix fanidan I chorak, Baxtiyor.uz-malumotnoma-namunasi, Doc1, ИУМ 2017-2018 1 курс (3 курс), ИУМ 2017-2018 1 курс (3 курс), Tajriba ishi 1, Mobil OT FanDasturi tuzatildi 2019, Kurs ishi, Kurs ishi
An architecture of any kind of complex man-made system, such as a cathedral or an office park, describes the
overall structure of the system: its major components and how those components interrelate.
13 Chen, Peter. The Entity-Relationship Approach to Logical Data Base Design. QED Information Sciences,
Inc., 1977.
Exhibit 9.: ERD diagram
The architecture of a business information system can be defined as the infrastructure and interfaces that enable
system components (such as hardware, software and network communications) to work together to accomplish the
system’s purpose. The architecture is defined for the system as a whole, rather than for each of its components. In
fact, the infrastructure and interface standards are usually shared among multiple systems. For example, all the
web-based systems in an organization, whether Internet or intranet, might share the same architecture.
Generally, the system architecture is imposed on a project team by the organization’s Information Systems (IS)
department. Depending on the needs of the business system, the project team may request changes to the
architecture, which are then typically implemented by a separate architecture team led by the organization’s
systems architect described in Chapter 3.
Sometimes, a new architecture is needed. This typically happens when an organization decides to use technology
in a novel way to take advantage of a business opportunity. In such cases, a new architecture may be developed at
the same time, or slightly ahead of, the business information system. A brand-new architecture can carry
tremendous risks and should only be undertaken after careful consideration by the systems architect.
Importance of architecture
Could you build an information system without an architecture?
Yes, it is possible to build small, isolated information systems without a formal architecture, just as it is possible
to build a log cabin without one. But as soon as you want to build a building which is larger or has multiple
components—an energy efficient home, an apartment complex, an office high-rise—you need an architecture to
show where the electric wiring, the plumbing, heating and air conditioning, the stairs and the elevators should go
and how they should work together.
The main role of a system architecture is to help manage the complexity and size of modern business
information systems. The architecture embodies important design decisions that have already been made. This is a
constraint on the team, which is not free to make decisions that run counter to the architecture, but it also means
that there is some kind of support within the organization—including knowledgeable people, development
guidelines, reusable code, and implementation experience with the architecture—making the team’s job easier.
The fact that many design decisions have already been taken has the following advantages:
• Risk reduction: first, the use of proven components and interfaces reduces the number of unforeseen
problems arising during system development and operation; second, technological innovation is easier to
control, because the architecture pinpoints the main risk areas, isolating them from what remains routine.
• Integration: well-architected systems are easier to integrate with each other and with legacy systems,
because the architecture defines and describes in some detail the points at which two systems are allowed
to interact.
• Productivity: an architecture is an investment—the stronger the architecture, the higher the productivity of
the development team after an initial learning curve. Developers can in a certain sense “reuse” the technical
decisions made by the system architect and less time is spent analyzing and testing alternative solutions.
• Reliability: the use of proven components and approaches that have already been successful in the specific
environment in which you are working reduces the total number of errors and makes it easier to find those
errors that do occur.
• Maintainability: standardized design and construction makes it easier for maintenance teams to correct,
enhance and extend them to a changing business and technical environment.
• Predictability: an established architecture has well-known technical characteristics, making it relatively
easy to analyze and predict performance, reliability, usability and other quality measures.
Selecting, extending or creating an architecture
On projects where both the business functionality and the technology are well understood, the project team will
be best served by adopting an existing architecture, with minor modifications where needed. If the system is small
enough, the architecture may not need to be specified in much detail. For example, a system may be simply defined
as being web-based: this implies a host of technical decisions, as will be illustrated in later chapters.
Of course, if some element is absent from the architecture needed for a project, the team may be free to add it.
This increases the risk and the cost, since no support will be available from the system architect and her team.
Where a new development project is driven by business innovation, it is best to adopt an existing, robust
architecture. This reduces the development risks by not adding technical risks to the business risks.
On projects driven by technology—when someone has had a novel idea for applying technology in a way that has
not been done before—you may well need a new architecture altogether. This architecture must at least be designed
before the requirements process goes too far. In most cases, it will need to be developed and tested on a pilot
project, to verify that the technology is workable and will help solve the business problem.
Finally, note that most of the systems “development” activity of existing IS departments is in fact maintenance.
Maintenance requests very rarely have an impact on the system architecture.
In summary, in most cases, the system architecture will be given at the outset of a development project, or at
least in its very early stages—certainly before requirements gathering is complete and before design has gone very
To design a system is to decide how the requirements formulated as described in the previous section and
approved by all the stakeholders are going to be implemented. The design process has two main focal points: the
future users of the system (external, functional, or user design) and the IS professionals who will code and test it
(internal or technical design).
External design
The first question of a design is, how will the users interact with the system?

Download 64.37 Kb.

Do'stlaringiz bilan baham:
1   2   3   4   5   6   7   8   9   10   11

Ma'lumotlar bazasi mualliflik huquqi bilan himoyalangan ©fayllar.org 2022
ma'muriyatiga murojaat qiling