Business Information Systems: Data Hierarchy and Competitive Advantage

This report delves into the critical role of information systems in modern businesses, emphasizing the significance of data and its hierarchical structure as proposed by Russel Ackoff. It explores how well-designed information systems contribute to business operations, conferring competitive advantages by leveraging data insights and developing effective strategies. The report evaluates business requirements and proposes solutions, addressing contemporary challenges and complex business needs related to information systems. It highlights the importance of a balanced business architecture, integrating technology and business needs, while also discussing data hierarchy components such as characters, fields, records, documents, and databases. The business model, its role, and the importance of aligning technology with business processes are also examined, providing a comprehensive analysis of information systems and their impact on organizational success.

Information Systems

Introduction
Information systems have become critical components for the modern business such that at
the core of the operational infrastructure of any business is its business information system. The age
of Information Technology has heralded the era of data, where businesses gather a lot of data about
clients, suppliers, the market, and other stakeholders and use this data to gain valuable insights and
develop suitable strategies that maximizes on the collected data. As per the hierarchy of data
proposed by Russel Ackoff, this paper discusses the concept of information systems with respect to
data and its hierarchy and shows how a well designed information system is beneficial to business
operations, and confers competitive advantages. The paper evaluates business requirements and
proposes solutions that have been testes and verified to solve contemporary business challenges and
also develops suitable strategies that can address complex business needs relating to their
information systems.
Discussions
Business leaders do not give the business architecture because they either appear too focused
on technology or are too complex and in the process failing to maximize on the benefits that a well
designed architecture have for any business. The challenge is in creating a balanced business
architecture that caters for technology and business needs. Separating a business from its enterprise
architecture is not the solution as it significantly diminishes the value and fundamental purpose of
the enterprise architecture (EA). An information system (IS) refers to a group of artificial objects or
devices or even an organization that form a network designed for the distribution of a service, for
example a computer or telephone system. These activities (systems) are developed b successful
businesses even if they are EA’s (Guetat and Dakhli, 2015). In the modern business environment,
business activities increasingly use data in, and documentation of business processes as a way of
increasing efficiency, creating clear responsibilities and role identities, and integrate activities
across departments. The norm is to mimic the information technology system or the business
architecture in creating the system, with the goal of aiding businesses to automate activities and
handle large data volumes in a meaningful and secure manner.
Often, there is a conflict of interpretation; technology people assume people in operations
have no understanding of technology and as such, cannot develop a comprehensive technical
architecture or system to describe technology services. On the other hand, people in operations have
the belief that the business architecture is the blue print that should guide the enterprise and often
assume, wrongly, that this is the business architecture. This divergence in opinion demonstrates the
challenge of developing a suitable EA for a business. EA is neither the system architecture
(technical) nor the business architecture (operational)- the EA, rather, refers to both these

architectures developed in an integrated manner created using standardized design methods, with
innovative data hierarchies and architectures so that they can be used by both the technology and
operations people (Cavallari and Tornieri, 2018). The goal of EA in developing IS is to establish the
methods, policies, and tooling to achieve these objectives. EA is a carefully designed business
structure or entrepreneurial economy activities that include processes, people, and systems working
harmoniously to generate important business outcomes. The structures entail operational processes
that provide value, organizational design, and systems utilized by people as they execute their
various roles and missions. The business prescribed operational results (end-states) are used by
enterprise architects as a blue print to guide the EA to meet the business needs. The end states
usually include goals, visions, capabilities, and objectives. As such, the overall architecture must
integrate technology with business processes.
Data Hierarchy
Organizations, especially medium to large scale ones, use information technology to handle their
needs for data solution and storage needs. The IT architecture is akin to a document that explains
the IT (Information Technology) and other IT elements of the organization works to achieve and
implement its objectives and goals. System architecture specifically addresses data sets, business
processes, software, technology, and information applications for an organization. The EA helps the
organization define the way technology changes can be implemented in the context of the business
goals (Soomro, Shah and Ahmed, 2016). The EA of an organization forms an integral part of its
strategic planning and overall business architecture and is as such a technical blue print for an
organization that should be aligned with business components. It is important tool that helps the
organization share relevant data and information across board and is also a useful tool for
collaboration and also aids an organization to respond better to changes in the technology and
business environment quickly while helping in cutting costs and improving organization
competitiveness. It is therefore prudent to develop a suitable technical architecture and then align it
with the business architecture. The broad structures of a system are defined by the system
development and the business architecture. The EA consists of sub units that include technology
architecture, business architecture, and information systems architecture (Cavallari and Tornieri,
2018).

The general accomplishment of accomplishing business results requires an authoritative
(joining) with the framework engineering (for instance, data innovation); generally, the design is
deficient. In car terms, the guiding wheel isn't associated with the vehicle's hub. These coordinated
ties guide or steer the framework engineering toward the procedures and results recognized in the
business side of the design. Designs are plans utilized as a manual for construct things—in
numerous occasions, data innovation, however not generally. Something else, what's the reason for
the design? Investigation of the business side alone (regularly the business forms and significant
results) builds up a guide of what's essential to the business. In any case, this methodology leaves
expanding openings in the jobs frameworks play toward these business results. Without an
engineering understanding between representatives and frameworks individuals, designers have a
free-for-all, which is the place we are today. Numerous pioneers place incredible expectation in
deft, which is a definitive free-for-all. In a general sense, EA is a structure (the two words and
photos) of the individuals, procedures, and frameworks required to effectively accomplish
significant business results of the undertaking. These structures are not the "as seems to be"
engineering; rather, they are the "to be" design. An undertaking design is a visionary diagram of
what the endeavor wants to be at some future state—a great part of the engineering, be that as it
may, may be current relying upon the development of your design practice. I recollect a visitor
speaker at a Department of Defense undertaking engineering meeting expressing, "I just designer as
a great part of the 'as is' procedure expected to modeler the 'to be' process."
Information Hierarchy Components
An information field holds a solitary reality or quality of an element. A filed that has a date,
for example, ‘September nineteenth 2004" can be regarded as a single filed or as three fields
because it has a day of the month, the year, as well as the month.
 A record refers to information with related fields for example the name of a staff member
can have the name filed, the position fled, birth date filed, and education field. A document
is an assortment of related records.
 If an organization has say 100 employees, then each must have a record with unique
numbers and these would make up a document with personal details of employees
 The documents make up a database and is managed or accomplished through a suitable
database management system and if the employees have different features to be captured,
then different documents will be generated, for instance the training history of an employee
and maybe their work history and leave days.

 Information is stored in layers and arranged in a hierarchical manner with every subsequent
higher level containing some elements or information from the preceding lower level
(Kearny, Gerber and van der Merwe, 2016).
Characters
In the ASCII coding plan, every byte speaks to a solitary character, which can be a number
(4), letter (R), space, accentuation mark (?), or other image (and).
Fields
A field is a mix of at least one related characters or bytes and is the littlest unit of
information a client gets to. A field name extraordinarily recognizes each field. The field size
characterizes the most extreme number of characters a field can contain.
Picture
The information type determines the sort of information a field can contain and how the
field is utilized. Regular information types include:
 Content (additionally called alphanumeric) — letters, numbers, or exceptional characters
 Numeric (additionally called number) — numbers as it were
 Auto Number — novel number consequently doled out by the DBMS to each additional
record
 Money — dollar and penny sums or numbers containing decimal qualities
 Date (likewise called date/time) — month, day, year, and here and there time
 Update — long content sections
 Indeed/No — just the qualities Yes or No (or True or False)
 Hyperlink — E-mail address or Web address that connects to a Web page on the Internet or
record on a nearby system
 Item — photograph, sound, video, or a record made in different projects and put away as a
bitmap in the database
 Connection — report or picture that is joined to the field, which can be opened in the
program that made the archive or picture (working likewise to email connections)
Records

A record is a gathering of related fields. For instance, an understudy record incorporates a lot
of fields around one understudy. An essential key is a field that extraordinarily recognizes each
record in a document. In certain tables, the essential key comprises of numerous fields, called a
composite key.
Documents
An information document is an assortment of related records put away on a capacity
medium, for example, a hard plate or optical circle. A database incorporates a gathering of related
information records (Kearny, Gerber and van der Merwe, 2016).
The Business Model
A plan of action mirrors the center business of an association. It depends on the idea that an
organization conveys items/administrations to clients. The plan of action should catch, at an
exceptionally elevated level, how an association acts to fulfill the clients' solicitations for
items/administrations. The plan of action doesn't show how the association is organized and works
so as to achieve its objective. These perspectives, which we term business design, are viewed as an
execution of the plan of action. Activities, for example, business process re-designing (BPR) and
authoritative rebuilding don't adjust the plan of action since they center around changing the
business engineering that executes the plan of action. Articles in the plan of action are not forms,
explicit operators, or database segments. Or maybe, they are jobs played by operators (e.g.,
individuals and offices) answerable for conveying administrations/items among themselves and, in
the long run, to clients. We use jobs, as they are less subject to the particular authoritative structure
and the execution of the business forms. In particular, a given operator can assume various jobs and
a similar job can be played by a few specialists. For instance, the top level plan of action for a
Wholesale Exclusive Distributor has three jobs (Customer Service/Support, Inventory Management,
and Business Administration) that work together to convey products and ventures to clients. We
don't determine who (e.g., divisions or establishments) assume the different jobs (Salomon et al.,
2017).
Essentially, the system for connecting innovation to business forms is demand driven. The
plan of action is formed by breaking down it into jobs dependent on the solicitations the business
needs to manage. This methodology is picked to guarantee exemplification, which with regards to
the plan of action implies that the real business execution (hierarchical structure and business
forms) would not make any difference in understanding the business. The procedure starts by first
distinguishing the outside items that send solicitations to the association (Salomon et al., 2017).
Outer articles are those that collaborate with, however are autonomous of and assume no jobs in

doing, the business. Since organizations frequently execute business exercises by utilizing outer
operators, we must be mindful so as not to bewilder the ID of outside articles with re-appropriating.
We settle this issue by considering jobs as opposed to operators. A few instances of outer items are
clients, controllers, and investors. For every outer solicitation, an assistance in the association is
relegated to process it. In the subsequent stage, comparative administrations are totaled together to
take out duplication of obligations. In the accompanying advance, each help is supplanted by an
article which speaks to a job in the association. Note that we don't speak to administrations as
articles.
Enterprise Architecture
Plans of action created utilizing the above strategy comprise of both human and registering
exercises. To get an IS engineering from the plan of action, we need instruments to recognize, in the
model, exercises that can be electronic. We propose to achieve this utilizing the ideas of agent and

static articles. Representative articles are liable for performing data handling exercises. The key
thought is that in an article (speaking to a job), some state factors mirror the condition of
information on the item, and a few administrations get to or work on these state factors. On the off
chance that these administrations are sufficiently organized to be modernized, at that point they can
be "designated" to a data framework part. The items we have talked about so far reflect jobs in the
association (Cai et al., 2017). Nonetheless, there are things about which we have to know, however
don't perform administrations. We, consequently, present the thought of static articles. A static item
type speaks to a sort of thing that the condition of which we have to know, yet has no duties in
maintaining the business. There is no methodical method for distinguishing agent and static items. It
relies upon what should be robotized or monitored. Clearly, one can't assign a duty that doesn't exist
in the plan of action or have a static item that isn't known by any inward articles. Since the current
IS design is doubtlessly going to be founded on social databases and, along these lines, unique in
relation to the perfect IS engineering gotten from the plan of action, which depends on objects, can
be switch interpret them by "generalizing" the database(s) in the current IS (Section 4.3). Since
databases just contain the static parts of business exchanges, elements (i.e., administrations to the
articles) are included by looking at all application programs that utilization or influences the
conditions of these databases.
Conclusion
Organizations are changing more quickly and giving a larger number of administrations than
previously. So as to help such a quick evolving condition, data frameworks (IS) must be adaptable
and simple to change. Since most associations have just contributed a ton of cash to build up the IS
they have now, it is preposterous and even difficult to supplant them. In this paper, we contend that
the way to help change is to attach existing IS usage profoundly business (i.e., the piece of the
business that is free of authoritative structure and business forms). To achieve this, we give a
strategy to create plan of action, to figure out existing IS, and to interface them together

References
Cai, Y., Cui, X., Huang, Q. and Sun, J. (2017). Hierarchy, cluster, and time-stable information
structure of correlations between international financial markets. International Review of
Economics & Finance, 51, pp.562-573.
Cavallari, M. and Tornieri, F. (2018). Information Systems Architecture and Organization in the Era
of MicroServices. Lecture Notes in Information Systems and Organisation, pp.165-177.
Corominas-Murtra B, Rodríguez-Caso C, Goñi J, Solé R. (2011). Measuring the hierarchy of
feedforward networks. Chaos. pmid:21456850
Guetat, S. and Dakhli, S. (2015). The Architecture Facet of Information Governance: The Case of
Urbanized Information Systems. Procedia Computer Science, 64, pp.1088-1098.
Gupte M, Shankar P, Li J, Muthukrishnan S, Iftode L. (2011). Finding hierarchy in directed online
social networks. In: Proceedings of the 20th international conference on World wide web. ACM; p.
557–566.
Kearny, C., Gerber, A. and van der Merwe, A. (2016). Data-driven enterprise architecture and the
TOGAF ADM phases. 2016 IEEE International Conference on Systems, Man, and Cybernetics
(SMC).
Laudon, K, C. & Laudon, J., P. (2007). Management Information Systems - Managing the Digital
Firm (9 ed.). Upper Saddle River, USA: Pearson-Prentice Hall. pp. 226, 229
Salomon, M., Mello, C., Salgado, E. and Bitencourt, M. (2017). Components to Construct a
Business Model Innovation Under a Product-Service System Approach in the Aerospace Industry
Through Analytical Hierarchy Process. Lecture Notes in Management and Industrial Engineering,
pp.29-37.
Soomro, Z., Shah, M. and Ahmed, J. (2016). Information security management needs more holistic
approach: A literature review. International Journal of Information Management, 36(2), pp.215-
225.