Case Study on Johnson and Johnson's Decentralized Operational Units

This report analyzes the challenges faced by Johnson and Johnson in their decentralized operational units and suggests solutions to improve efficiency and standardization. The main problems include duplication of work, high overhead costs, lack of centralized control, and lack of standardization. The proposed solutions include implementing distributed systems and using ERP systems. The report also discusses the application of the Zachman Framework in describing the architecture of the proposed system.

Report 1.1 Case Study
Main Problems
This report looks into the Johnson and Johnson case study on the decentralised operational units that deals
with the pharmeceutical’s customers. From the given case study, the following are some of the key
challenges faced by the company in its current state of decentralization
Duplication of work; With this type of architecture, the various operational units of the company risk
having duplicate sources of information referring to one entity in the company. This is due to the fact that
every operational unit works in its isolated environment and keeps its own data sets. The duplication of
work and data across different departments potentially leads to data integrity issues and seems to be
uneconomical to sustain (Robert Lagerström et al., 2019).
Decentralised systems currently maintained by Johnson and Johnson has huge overhead in terms of cost
to the company due to lack of centralized systems. Those resources that can be converted into shared
services in continuously being a burden to the company as it has to cater for its budgetary needs of the
various decentralised operational units (Nikpay et al., 2017)
Another key problem faced by the company is the lack of a centralised control system onto the business.
This is a serious problem as their can arise some conflicting ideas and clashesa in the policy in the various
operational units. This can potentially lead to delays in the decision making process.
Last but not the least, the problem of standardization which currently lacks in the company is inevitable in
the current centralised approach. It is very difficult to implement data standards in various levels and
operation units since the seems to be autonomy and independence among various operational units. This
lack of proper standards and best practices in implementing the IT infrastructure can potentially cause
loopholes into the company IT infrastructure an adversaries could use the lack of standards in the
company to exploit given security vulnerabilities that are always prone especially in companies without
standards (Vallerand, Lapalme and Moïse, 2017).

Solutions
The key solution to this challenge is for the company to setup distributed systems. This architecture which
is partly centralised and partly decentralised can be very much applicable to the current situation the
company faces. The centralised part gives the company a centralised way to manage the company and its
resources whereas the decentralised nature of the architecture shall ensure each unit has a more focused
approach to implementing those systems and applications that meet their particular business needs. Such
systems are normally custom made hence are generally used by a particular business unit within the
company's general IT infrastructures. Alternatively, the company can use the ERP system backed by a
centralised database that can be used to model the customer entity. This system should store all the
information about customers and each operational unit within the company should be able to access this
data after authentication and authorisation.The ERP system has several advantages as it is easily scalable
to meet the growing business needs. Again, ERP makes sharing of data much more easier and efficient
across departments and branches (Kitsios and Kamariotou, 2019)
Zachman Framework Application
Zachman Framework is utilised by information technology system developer in their attempt to describe
the architecture which is currently in use by a given entity and the various envisioned architecture for the
future systems to be built. The information technology discipline normally has a lot of diagrams and
artifacts which are critical for the architecture. The Johnsin and Johnson company can utilise the ZAF
architecture to describe the various needed architecture for the new system to be built and the
relationships between the different architectures. The ZAF matrix is useful for the company to
progressively describes the proposed solution to be built from a top to bottom manner, where the top level
contains the high level information about the proposed system and the down level have a more detailed
architecture of the proposed solution (Bente, Langade and Bombosch, 2012).The levels that can be used
to describe the proposed Johnson and Johnson system includes
Contextual; This answers the what question. That is what is the domain of the architecture discussion
Conceptua; Tsh level can be used to answer the How question. How will the centralised system be build?l
Logical; This level answer the what question.Questions like what will most make sense for the company
to build for the centralisation approach

Physical; This level answer the question on what the proposed solution shall look like after its
implementations
Detailed; This is the bottom level and answers the what the developers and implementers actually need to
do to achieve the contextual level needs.
The essential model for the company ERP would look like this
Why How What Who Where When
Contextual Goal list Process List Material
Unit
Organizatio
nal unit and
Role List
Geographica
l locations
lists
Even list
Conceptual Goal
Relationship
Process
model
Entity
Relationship
Diagram
Organizatio
nal Unit and
Role Model
Locations
Model
Even Model
Logical Rules
Diagram
Process
Diagram
Data model
diagram
Role
relationship
Diagram
Locations
Diagrams
Even
Diagrams
Physical Rules
specification
s
Process
function
specification
s
Data entity
specification
s
Role
specification
s
Location
specification
Event
specification
s
Detailed Rules details Process
details
Data details Role details Location
details
Even details

Report 1.2
The University of Newcastle has proposed the following processes to the enterprise architecture,
Design programs
The process of design and continuous improvement of the various degree programs that students get
enrolled into. The continuous improvement ensures the student get value of their money and achieve the
strategic goals of attracting more students All the designed programs hence must be evaluated to meet the
market needs.
Attract students; The enterprise architecture shall attract be used to attract more and more students by
putting in systems to understand the market targets, promote the university to the outside world, Provide
necessary data and information regarding the programs offered by the university, Provision of
scholarships to bright needy students to further conduct research and development (Oswaldo Moscoso-
Zea, Joel Paredes-Gualtor and Sergio Luján-Mora, 2019)
Enroll students; The enterprise architecture process of enrolling students entails the set and verification of
the programs, set and verification of courses, Publishing the programs and courses offered, set up and
verify the timetable for student and lectures.
Invoice students; The EA is tasked with the process of invoicing students by setting up and verifying the
charges, publishing the fees charges, configuration of rules on fees, Running the tuition calculation
process, Run the billing process and reconciliation of income for compliance purposes (Dierk Jugel,
2018).
Process of payments and fundings; The EA shall achieve this process by receiving payments, and
applying the payment received against the debts of the student.

Comparison EA-Zachman, TOGAF, FEA, GARTNER
Based on the various levels of the enterprise architecture, the following comparisons can be drawn from
the four widely used enterprise architectures
Winter and the
Fischal layer
Layer Business
Architecture
Layer Process
architecture
Layer
Integration
Architecture
Layer
Software
architecture
Layer
technology
architecture
Zachman
Framework
The very first
row have the
scope context
of the
envisioned
project as it
answers
questions like
(What, how,
when,who,why
)
The second in
this model
focus on the
business
concepts such
as (what, why,
when, who,
why,)
Here focus is
made to the
system logic
which
encompasses
questions
like(what,
how,where,wh
o,when,why)
At this layer,
the various
technology
physical is
defined. This
answer
questions such
as(what,
how,where,wh
o,when,why)
This defines
the component
assemblies and
answers
questions such
as (what,
how,where,wh
o,when, why)
TOGAF The TOGAF
Business layer
defines the
business
strategy,and
the general
organizational
governance
This layer in
TOGAF is
used to define
the key
business
processes
In TOGAF, the
integration
layer provides
the specific
blueprint for
the individual
application
that are
suppose to be
deployed into
the new system
the interaction
Here, the layer
defines the
various data
assets of the
company and
the logical and
physical
representations
of the data
assets and the
management
of the key
This layer in
TOGAF
defines the
hardware and
software
capabilities of
all the software
and hardware
included in the
EA,

among the
different
components to
be deployed
resources
FEA The normally
defines the
vision, the
goals and
mission of the
system
envisioned to
be developed
The FEA
defines all the
aspects of the
process and
services to be
offered by the
proposed
system
Here the level
defines the
details aspects
of the system
and
applications
needed to
ensure the
proposed
changes are
made into the
EA
In the FEA
architecture,
this layer
defines all the
aspects of data
and
informational
aspects of the
application
This layer in
FEA defines
the logical and
physical
infrastructure
GARTNER This strategic
view focuses
on the desired
outcomes of
the systems to
be developed
This layer
defines the
operational
view of the
solution. It is
more abstract
definition than
physical terms
Here the
Service
Oriented
Architecture is
used to
describe the
key services
which are very
important for
the operation
of the
applications
This layer
defines the
operational
views in
abstract rather
than physical
the various key
processes,
information
needs and the
various entities
This layer
models the
system view
and used to
describe the
key physical
implementatio
n and the
overall
operation of
the service
oriented views
and give
definitive
solutions

Relationship between EA and SOA
The EA is primarily used to align the business and IT from the strategic perspective while the SOA is
primarily used to align the business and IT from a technology perspective. Conventionally, EA focuses on
the crafting of a key plan rather than the actual implementation of the proposed solution whereas the SOA
conventionally focuses on the implementation of the plan once it is done by the EA. The two frameworks
aims at providing a guidelines that ensures the organizational business neesa are well supported by the
various investments in IT. The two concepts therefore can not be dealt with in silos as they are closely
related (Brahm, 2017).
Report 1.3 ERD
Milk Dairy

QuickFix Electronics

Report 1.4
EA and Big Data
Root causes of Failures of Big Data
From the case study, the following key factors have been identified as the root causes for the failures of
the Big data projects
Management resistance; The management have been seen to normally trust their guts as opposed to
analytics from big data hence giving little or no attention to the potential of big data projects (Hacks et al.,
2019)
Wrong use case; The case study shows very high ambitious projects which the company was not ready to
handle based on the limited expertise on the subject matter. The technology they chose was not optimized
for big data hence the failures
Misalignment with the corporate strategy. The Big data projects can only succeed if they are not in
isolation but should be at the core of the business operations. Big data projects tends to fail in cases where
the business has other important projects that they cannot devote enough resources to the big data project
(Jefree Fahana and Ahmad Azhari, 2018).
Not asking the right questions; The case study example shows a situation where the companies tend to
hire data scientists who may be genius at programming but lack the business domain knowledge hence
flops at the big data projects.
EA support for Big Data Projects
The Big data project’s success can be accelerated by incorporating elements of EA in the contextual,
conceptual, logical, physical and detail designs of this project. This ensures their is great alignment
between the project's goals and the company's strategic goals. The EA hence provides the bigger picture
of the proposed project which is critical in soliciting resources from the project sponsors. The values from

the project manager can then be used to implement the big pictures view (Jefree Fahana and Ahmad
Azhari, 2018)
EA and Cloud Computing
From the case study, the following are key recommendations to ensure their is application security and
encryption;
All the university key management enterprise architecture should be responsible in creation and
management of the encryption keys
The data stored in the cloud computing environment should be subject to encryption
The encryption method developed should confirm the standards developed in the field of cryptography to
achieve interoperability
There is a need to check if the data leaving the provider's network is subject to encryption to ensure the
data is safe while on transmit from node to node

References
Bente, S., Langade, S. and Bombosch, U., 2012. Collaborative Enterprise Architecture :
Enriching EA with Lean, Agile, and Enterprise 2.0 Practices. [online] Burlington: Morgan
Kaufmann. Available at: <http://165.193.178.96/login?url=http%3a%2f
%2fsearch.ebscohost.com%2flogin.aspx%3fdirect%3dtrue%26db%3dnlebk%26AN
%3d477515%26site%3deds-live> [Accessed 5 Sep. 2019].
Brahm, M., 2017. Seeking to control enterprise with architecture : the limits and value of an
engineering approach from the perspective of an enterprise architect.
Dierk Jugel, 2018. Modeling Interactive Enterprise Architecture Visualizations: An Extended
Architecture Description. Complex Systems Informatics and Modeling Quarterly, (16), p.17.
Hacks, S., Höfert, H., Salentin, J., Yeong, Y.C. and Lichter, H., 2019. Towards the Definition of
Enterprise Architecture Debts.
Jefree Fahana and Ahmad Azhari, 2018. TOGAF for designing the enterprise architecture of
LAZISMU. Bulletin of Social Informatics Theory and Application, (2), p.58.
Kitsios, F. and Kamariotou, M., 2019. Business strategy modelling based on enterprise
architecture: a state of the art review. Business Process Management Journal, 25(4), pp.606–
624.
Nikpay, F., Ahmad, R., Rouhani, B., Mahrin, M. and Shamshirband, S., 2017. An effective
Enterprise Architecture Implementation Methodology. Information Systems & e-Business
Management, 15(4), pp.927–962.
Oswaldo Moscoso-Zea, Joel Paredes-Gualtor and Sergio Luján-Mora, 2019. Enterprise
Architecture, an enabler of change and knowledge management. Enfoqute, (1), p.247.
Robert Lagerström, Alan MacCormack, David Dreyfus and Carliss Baldwin, 2019. A
Methodology for Operationalizing Enterprise IT Architecture and Evaluating its Modifiability.
Complex Systems Informatics and Modeling Quarterly, (19), p.75.
Vallerand, J., Lapalme, J. and Moïse, A., 2017. Analysing enterprise architecture maturity
models: a learning perspective. Enterprise Information Systems, 11(6), pp.859–883.