Johnson & Johnson Enterprise Architecture Project: Portfolio 1.1-1.4

This project is an in-depth analysis of Enterprise Architecture (EA), using Johnson & Johnson as a case study. The project begins by identifying the main problems faced by the organization, such as a complex business environment and decentralized IT systems. It proposes the Zachman Framework as a solution, organizing existing functions, elements, and processes. The project then compares various EA frameworks including Zachman, TOGAF, FEA, and Gartner, evaluating their completeness, business focus, and time to value. It discusses the relationship between EA and SOA, highlighting the value that an EA program delivers, such as guidance and control, while also addressing associated risks like lack of understanding and user acceptance. The project further explores value creation through strategic planning, improved communication, and tactical improvements. It examines risk management methods, including mitigation and exploitation, and emphasizes the importance of aligning IT with business strategy. The project then delves into EA implementation methodologies, comparing frameworks and methodologies, and the importance of communication and stakeholder support. It also examines the phases of an EA implementation methodology, and the documentation used, including artifacts, diagrams, and vendor-supplied documentation.

Portfolio 1.1
Main problems for the organisation
The main problem of Johnson and Johnson is the complex business environment, A
decentralised company with a group of 150 company and the managers are answerable for the
results of their companies and customer facing difficulties while dealing with multiple
invoices and the contract with the operating companies, because the legacy technology
unable to support the business going forward. There is no standards and decentralised IT.
Solutions we propose to solve these problems
For the Johnson and Johnson case study I am going to propose Zachman Framework to solve
these problems. Zachman Framework organises the existing functions, existing elements and
processes.
Zachman Framework
Zachman Framework is a two dimensional scheme for expressive depictions of an
Enterprise. Most of the methodology is organised in the development phase but Zachman
framework organised the organisation of view taken by the various player
The Zachman framework provide the responses of “What”, “How”, “Who” and “Where”
across dimensions – Business Requirements, Conceptual Model, Logical or Physical Model
and Actual Implementation.
In the Johnson and Johnson case study Zachman framework associate the business, process,
people and technology. Each cell has to be documented in detail and information is gathered
by questionnaires (subjective and objective).
Followings are the Zachman Framework which is used for Johnson and Johnson case study to
solve these problems:
Data (What) Technical
Architecture
(How)
People
(Who)
Infrastructure
(Where)
Business
Requirements
Information
Requirements
Data
processing
needs of
business
Business
User
Business
application
Conceptual
Model
Conceptual
Overview
Data
information
and Analysis
User
Community
Modelling
tools and
documentation
Logical or
Physical Model
Physical
overview
Application
architecture
and reporting
environment
Data
Modeller and
DBA
System
architecture
and geological
location of
system
Implementation Physical
Infrastructure
ETL
Processing
Development
and
Hosting
requirements

and
Reporting
Infrastructure
maintenance
Team
Portfolio 1.2
Followings are the process which is proposed for EA:
Enterprise Architecture Compliance Process
Enterprise Architecture Governance Process
Project Engagement Process
Enterprise Architecture Management Process
Compare the frameworks for EA- Zachman, TOGAF, FEA, and Gartner
Comparison table with some criteria:
1. Does very good job in this area
2. Does an inadequate job in this area
3. Does poor job in this area
4. Does acceptable job in this area
Criteria Rating
Zachman TOGAF FEA Gartner
Completeness of
Taxonomy
1 2 2 3
Process
completeness
3 1 2 4
Practice
guidance
3 2 2 1
Business Focus 3 2 3 1
Information
availability
2 1 2 3
Time to value 3 4 3 1
Relationship between EA and SOA:
The simple relationship between EA and SOA is like a contractor and electrician or plumber
who helps to design a structure and maybe physically build it. The Enterprise Architect
provides the basic design from the standpoint, functionality and resource allocation, while the

SOA bring the exact services and ensure the operation. Generally SOA is used to build a
better IT organization, and EA provide the process and approach.
Portfolio 1.3
Milk dairy
Quikfix Electronics
Portfolio 1.4

Week-3:
1. Followings are the value that enterprise architecture program delivers:
Guidance: It identifies the core competencies and the priorities of business. It provides the
way how to create and manage the technology portfolios. How we can rationalize the existing
system and how to deduct cost and redundancy.
Control: Enterprise Architecture addresses all affected areas and reduces the risk
2. Followings are the risk associated with implementing an EA program:
1. Lack of understanding
The adoption rate of EA is very low, because the stakeholders do not participate in the
EA program.
2. User acceptance level low
3. Solution Cost is high
4. Security vulnerabilities and exposures
3. The management translate the vision and strategy into strategic goals the plans will support
these goals is significant business practice that need to take intellect from the business and
ICT specialists. Interpreting these goals into variations to the business processes, everyday
processes and ICT schemes are where Enterprise Architecture provides real value.
4. Enterprise architecture (EA) is an exercise of analysing, designing, planning and
implementing enterprise analysis to effectively perform on business tactics. It helps
businesses organization IT projects and policies to achieve chosen business results.
5. EA develop business and IT association by producing a mutual appreciative of business
strategy between IT and business departments, it articulate how the technology can drive the
business strategy. It optimises the technology and ensure for best business results and in step
with new technology.
6. When we work on a project we are confident that our project will definitely success, but
there is always a possibility of failure. When the things might go wrong is called the risk, and
in project management team identifies it early in the beginning of the project. So the project
management team can do some possible things.
Followings are the two method of manage risk:
Mitigate the Risk: Here we bound the effect of risk, so that when it occur the difficulties is
lesser and easy to solve.
Exploit the Risk: here we look for the way to mark the risk occurs so we can train the people
for future use.
7. The EA closing the space between IT departments and business units, Enterprise
Architecture begins the relations between strategy and structures, processes, databases, and

technologies. EA provide combined view of its business and IT architectures, it is not only
was active in massively refining performance but also measured effective risk by letting for
the coexistence of old and new procedures.
8. a. Followings are some potential value that an EA program would provide:
Improving strategic planning:
EA is like a bridge between the strategies and its implementation in the large organisation. In
large organisation we have various departments and they are not all completely in sync, and
we face disconnection between the departments. In this scenario the EA works as a
framework to ensure no department is overlooked, and each department in the large
organisation is working towards the same goal.
Better Communication:
EA help the organisation to improve the communication.
Tactical Improvement:
EA identifying the discrepancies (Example: redundancies, different department holding
separate licenses, decentralised IT, etc.) Enterprise Architecture can save an organisation both
time and money.
b. Followings are the areas of potential risk to implementation and acceptance of an EA in a
large sized business:
Disagreement regarding the requirement
Facing difficulties while using EA
Inadequate implementation of EA
Low level designed EA process
Incompatibility issue between work and EA process
Lack of resources
Lack of organisational security
Followings are the strategies to mitigate these risks:
Control: Implement an action to minimize the risk
Transfer: Reassigning the organizational responsibility, accountability etc.
Watch/Monitor: Monitor the change environment
Avoid: Adjust the requirement. This change can be quartered by change in funding, schedule
or technical requirement

Assume/Accept: Take a choice to agree the risk without appealing in special efforts to control
the risk
c. Enterprise Architecture Finding and examining the new ideas in the organization the
enterprise architecture team estimates ideas assemble a business case for pursuing these
ideas.
EA examines the risk, schedules, effects on corporate goals and how the changes will be
guarded by the principles and controls of the organization.
EA provide a plans and advises the alternate solution which describe the coming impact of
the change, it also include the estimated cost, risk, resources, etc.
Week-4:
1. Enterprise Architecture Implementation Methodology (EAIM) makes a established
approaches and performs for developing, managing, and maintaining the enterprise
architecture implementation. The uselessness in current EAIMs due to difficulties evolving
from EAIM practices, models, factors, and strategy.
2. EA Methodology is generally a guideline for resolving a problem, with specific
machineries like tasks, methods, techniques and tools. But the EA framework describes how
to make and use an EA. It offers values and observes for creating and consuming the
architecture explanation.
3. The purpose of Phase I activities in EA methodology is to identify the key players,
communicate with the implementation plan.
Develop communication plan, establish the EA governance and link to the management
process
4. Because in the phase III activities the actual development occurs, and in the phase II
activities we are selecting the chief architecture and the Enterprise Architecture Team
(Resources) and without selecting the team member we can-not start the actual development,
so it is necessary to complete the phase II before starting the phase III.
5. In the phase II we only select the resources for enterprise architecture project, select the
documentation process, software application tool etc. but in the phase IV of enterprise
programming the project is ongoing, hare we update the current and future views, maintain
EA repository, release update etc.
6. Yes the steps of the EA methodology be changed for the different enterprises.
7. The responsibilities for execution of the EA Program and EA methodology needs
somebody in responsibility to put on the correct framework and the correct tools and the
individual needs to be hold responsible and accountable.

8. As we work with Enterprise Architect we know the additional features contained in other
editions, which we want to use so we update the edition for making it more specific. Suppose
we work on a private model using the Professional edition and we need to expand the project
and we need a team to contribute so decides to use security to encourage collaboration
between the users and it require an upgrade version.
9. a. Followings are the phases and steps of an appropriate EA implementation methodology:
Initial Planning
Preliminary business model
Data architecture
Application architecture
Implementation plan
Planning conclusion
Transition to implementation
b. Good communication between practitioners and stakeholders is critical finding the
information needed to drive architecture and consequently.
We have multiple ways to obtain the EA stakeholder support will be obtained:
Ask about their role
Ask them what is wrong and how it should be fixed
Ask the best way to communicate with the organisation
c. Followings are the recommended schedule for updating EA:
Define the enterprise scope
Determine the future strategic direction
Documentation of current architecture
Design the future architecture
Perform the gap analysis
Week-7:

1. Current views of EA components are verify what resources and IT are used to support the
business achievement, it helps as a allusion starting point for planning and decision making.
Current view presents AS-IS view of the organisation, It reveals the dependencies,
association and the performance gap between current and required capabilities.
2. Artefacts are the real papers which define the EA mechanisms at each level of the
framework. It contains reports, diagrams, charts, spreadsheets, videos, etc.
It gathers the essential artefacts which need to create the “AS IS” view of the Enterprise
Architecture
3. Followings are some example of goal and initiatives of EA3 Cube framework:
Mission statement
Strategic plan
Performance measures scorecard
Concept of operation scenarios
4. IDEF-0 is suitable for the business process documentation and it provide the high level
context views, of each step and that can be further decomposed and interrelated to other.
IDEF-0 uses input, output, mechanism and control to show the part of an activity.
5. Followings are the difference between ERD, DFD and UML:
I. DFD only provide the flow of data ERD provide the how the database look like and
UML provide the detail view of system
II. DFD provide each process, in ERD all entities represent, UML shows the system
behaviour.
6. The types and methods of documentation to be used in architecture area, also includes
repository for example:
System interface diagram
Communication diagram
Data flow diagram
System performance matrix
System interface matrix
7. Yes, the vendor supplied documentation is important to retain as EA artefact because it
provide diverse levels of detail. Explanations in EA artifacts can range in their granularity

from very high-level abstractions (for example: capabilities, executive-level considerations,
etc.) to pretty low-level details (e.g. detailed business activities, IT systems etc.)
8. Network Connectivity diagram
Building blueprint
Network Centre Diagram
Cable plant diagram
9.
a. Identify current strategic goals, initiatives, and outcome measures.
Followings are the strategic goal: use common methodology and repository for all
Smooth flow of information
Initiatives: It enforcing common principles to all.
Outcome measures: outcome as a form of feedback process for future work, estimating ROI,
capital planning, etc.
b. Identify current LOBs, business services, and associated activity/flow diagrams.
In any public or private organisation LOB (A Line of Business) is a distinct area of activity
within the enterprises. Followings are some list LOBs, business services, and associated
activity:
Skill consideration
Training requirement
IT related security
Service activity
c. Identify current information flows and data documentation in each LOB.
Data flow involves in the development of data models and it shows the structure of enterprise
business service. It is modelled and utilise using the different methods (traditional or object
oriented). Data flow reflects the process that transform the data within the current system it
involves the creation, update or deletion. The documentation enhances the data and
information flow in the public or private business organisation.
d. Identify the current IT systems and applications that support information flows for each
LOB.
Relationship diagram, Data flow diagram, database, front or back office service, application
software, multimode ERP solution etc.

e. Followings are some current IT infrastructure and networks that host IT systems and
applications:
Application: support the delivery of enterprise application
Infrastructural management tool and services: manage all elements of infrastructure, tool for
configuration, monitoring, authentication etc.
Server: physical and virtual server for premises
Storage: Data storage
Network: Routers, switches, firewall etc.
Portfolio 1.5
EA and Big data:
Roots cause behind the failure of big data projects:
Followings are some root causes behind the failure of big data projects:
Lack of data: poor data quality and accuracy
Structure of data: Inaccurate, outdated and incomplete data
Complex models: the data scientist goes with complex model building when the simple one
can be as good
Enterprise Architecture can support successful big data project implementation:
Followings are the Enterprise Architecture support in big data project implementation:
Innovation: Enterprise Architecture provides the value of using big data more effectively.
For example we have lots of data which could be beneficial for organisation but we also have
limitation. In this situation EA helping the business organisation to identifying where to
spend the effort.
Planning: Enterprise Architecture will break the general strategy and translating the business
requirements into architecture requirements. It will help to understand delivery and cost
issues and reconcile the new strategy.
EA and Cloud computing:
Important recommendations deal with application security and encryption:
Followings are the important recommendations deal with application security and encryption:
Big Data Cryptography: By developing a system to search and filter encrypted data like
searchable symmetric encryption (SSE) protocol.

Access Control: Restricting user access and granting the user who can access
Data privacy: It control the data leakage from multiple data base
Compliance and Security Monitoring: It is recommended that to apply Big Data analytics by
using tools like Kerberos, Secure Shell (SSH) etc.
Validation: It is recommended to use validation
References:
1. Lankhorst, M. (2009). Introduction to enterprise architecture. In Enterprise
Architecture at Work (pp. 1-11). Springer, Berlin, Heidelberg.
2. Lankhorst, M. (2009). Enterprise architecture at work (Vol. 352). Berlin: Springer.
3. Minoli, D. (2008). Enterprise architecture A to Z: frameworks, business process
modeling, SOA, and infrastructure technology. Auerbach Publications.
4. Cummins, F. A. (2002). Enterprise integration: an architecture for enterprise
application and systems integration. John Wiley & Sons, Inc..
5. Urbaczewski, L., & Mrdalj, S. (2006). A comparison of enterprise architecture
frameworks. Issues in Information Systems, 7(2), 18-23.
6. Chorafas, D. N. (2016). Enterprise architecture and new generation information
systems. CRC Press.
7. Vanauer, M., Böhle, C., & Hellingrath, B. (2015, January). Guiding the introduction
of big data in organizations: A methodology with business-and data-driven ideation
and enterprise architecture management-based implementation. In 2015 48th Hawaii
International Conference on System Sciences (pp. 908-917). IEEE.
8. Krafzig, D., Banke, K., & Slama, D. (2005). Enterprise SOA: service-oriented
architecture best practices. Prentice Hall Professional.
9. Erl, T., Carlyle, B., Pautasso, C., & Balasubramanian, R. (2012). Soa with rest:
Principles, patterns &constraints for building enterprise solutions with rest. Prentice
Hall Press.
10. Tang, L., Dong, J., Zhao, Y., & Zhang, L. J. (2010, July). Enterprise cloud service
architecture. In 2010 IEEE 3rd International Conference on Cloud Computing (pp. 27-
34). IEEE.

11. Crawford, K., Gray, M. L., & Miltner, K. (2014). Big Data| critiquing Big Data:
Politics, ethics, epistemology| special section introduction. International Journal of
Communication, 8, 10.