TOGAF 10: Understanding the 7 Core Concepts

Introduction

TOGAF 10, the latest version of The Open Group Architecture Framework, is a crucial tool for IT companies and organizations looking to streamline their enterprise architecture practices. This article explores the seven core concepts of TOGAF 10, providing a comprehensive understanding of how they contribute to the efficient management and development of enterprise architecture.

1. Definition of Enterprise

In the context of TOGAF, the term “Enterprise” refers to any organization or group of organizations with a shared set of goals. This can include corporations, divisions within a company, partnerships, or any other entity with a defined mission. Enterprise Architecture (EA) involves the practice of analyzing, designing, planning, and implementing the architecture of the enterprise to achieve these objectives.

2. Architecture Domain (BDAT)

TOGAF divides enterprise architecture into four primary domains, collectively known as BDAT:

Business Architecture

Business Architecture focuses on business requirements. It outlines the structure and operation of an organization, including business goals, functions, processes, and organizational structure.

Data Architecture

Data Architecture pertains to the management of data, both physical and logical. It involves data assets, databases, data models, and the governance of data across the enterprise.

Application Architecture

Application Architecture describes individual applications and their interactions. It addresses software applications and their role in supporting business processes and functions.

Technology Architecture

Technology Architecture involves the IT infrastructure, including hardware, software, networks, and services. It ensures that the infrastructure supports the application and data requirements of the business.

3. ADM (Architecture Development Method)

The Architecture Development Method (ADM) is the core of TOGAF. It provides an iterative approach to developing and managing enterprise architecture, consisting of the following phases:

Preliminary Phase

Preparation and definition of the architectural framework.

Phase A: Architecture Vision

Establishing the architectural vision to align stakeholders and define the scope.

Phase B: Business Architecture

Developing the business architecture to understand the structure and operation of the organization.

Phase C: Information Systems Architectures

Creating data and application architectures that support business processes.

Phase D: Technology Architecture

Developing the technology architecture to ensure the IT infrastructure meets the needs of the business.

Phase E: Opportunities and Solutions

Identifying opportunities and solutions for improvement and innovation.

Phase F: Migration Planning

Planning the migration from the current state to the target architecture.

Phase G: Implementation Governance

Governing the implementation to ensure alignment with the architectural vision.

Phase H: Architecture Change Management

Managing changes to the architecture to maintain alignment with business goals.

Requirements Management

Continuous management of requirements to adapt to day-to-day changes.

4. Deliverables, Artifacts, and Building Blocks

Deliverables

Deliverables are formally released and approved outcomes of each phase, such as reports, architectural models, and design documentation. They provide specific input to subsequent phases or meet stakeholder needs.

Artifacts

Artifacts include models, diagrams, and documents that describe specific aspects of the architecture. They serve as means of communication and documentation for various stakeholders and can be catalogs, matrices, or diagrams.

Building Blocks

Building Blocks are reusable architecture components that can be combined to create more complex solutions, ensuring consistency and efficiency in architecture development.

5. Enterprise Continuum

The Enterprise Continuum is a conceptual model for classifying and organizing architectural artifacts. It includes:

Architecture Continuum

Covers architectures from specific to general, providing a framework for developing and maintaining a comprehensive set of architectures.

Solutions Continuum

Covers technology solutions and their implementations, ensuring alignment with the architectural vision and business needs.

6. The Architecture Repository

The Architecture Repository is a structured repository containing all information relevant to the enterprise architecture, including:

Metamodel Content

Metadata definitions that provide a framework for understanding and managing architecture data.

Architecture Landscape

Current, target, and transition architecture models that provide a comprehensive view of the enterprise architecture.

Reference Library

Reference models, guidelines, and best practices that support architecture development and governance.

Standards Information Base (SIB)

Architecture standards and guidelines that ensure consistency and compliance across the enterprise.

Governance Log

Logs of architectural governance decisions, ensuring transparency and accountability in architecture management.

7. Architecture Capability

Effective enterprise architecture requires a set of capabilities, including:

Organization

Organizational structures and roles that support the architecture.

Processes

Processes for developing, governing, and managing the architecture.

Information

Data and information necessary to support architectural decisions.

Tools

Software tools and technologies that facilitate architecture development and management.

Skills

Skills and training required for personnel involved in architecture, ensuring they have the expertise to develop and manage the architecture effectively.

FAQs

What is the purpose of TOGAF?

TOGAF provides a framework for developing, managing, and governing enterprise architecture, ensuring alignment with business goals and efficient use of IT resources.

How does TOGAF define an enterprise?

In TOGAF, an enterprise refers to any organization or group of organizations with a common set of goals, including corporations, divisions, partnerships, and other entities with a defined mission.

What are the four domains of enterprise architecture in TOGAF?

The four domains are Business Architecture, Data Architecture, Application Architecture, and Technology Architecture, collectively known as BDAT.

What is the ADM in TOGAF?

The Architecture Development Method (ADM) is the core of TOGAF, providing an iterative approach to developing and managing enterprise architecture through various phases.

What is the Enterprise Continuum in TOGAF?

The Enterprise Continuum is a conceptual model that helps classify and organize architectural artifacts, including the Architecture Continuum and Solutions Continuum.

Why is an Architecture Repository important?

The Architecture Repository is essential for storing all relevant information about the enterprise architecture, ensuring consistency, accessibility, and effective management.

Conclusion

Understanding the seven core concepts of TOGAF 10 is essential for any IT company or organization looking to streamline their enterprise architecture practices. By leveraging TOGAF’s comprehensive framework, businesses can ensure their architecture aligns with their strategic goals, improves efficiency, and supports innovation.

Major.Minor.Patch


Every time you release a public (API) software you must update his version number.

The (public) version is universally composed by 3 numbers separated by a point:

Each version number has a semantic representation

The pattern is 

Major.Minor.Patch

Ex: in version number 10.2.5

10 is the Major version

2 is the Minor version

5 is the Patch version

All of these 3 numbers are always 

Incremented

NEVER decremented

Positive starting by 0

Patch number

It is incremented each time the release is about fixing some bug without affecting the already existing public interface

So if you see a version number like: 1.1.5 it means the last 5 releases were about fix bugs.

Minor number

As opposed to Patch, Minor means that they have been released new (interesting) public feature, without impacting old ones.

When there is a new Minor release the Patch number is restarted to 0. Of course, together to new feature, it’s possible that also some bug fixes have been released (even though the Patch number is 0)

Major Number

When the Major number is incremented the release contains new (fantastic) features, buuuut it means that all the old features are not anymore compatible! So if you depend on those, pay attention.

If you think about it, these versioning rules could be applied also to humans.

Each 1st of January we always have new proposals for our self, so it’s like we “would” change our Major version. Or whenever we learn something new we could upgrade our Minor version.

But when do we change our Patch Number? Maybe each time we have makeup?

How to implement unstable behavior / requirement

The customer, as we know, is always right even when he returns on his steps, and he forces you to review / rewrite a behavior for a component that seemed clear.

But the worst has not yet arrived, because the user can ask to change that requirement again, or worse, put things back as they were before.

Fortunately, Object Orientation comes to your aid with one of the most important design principles.

“Identify aspects of application that vary and separate them from what stays the same.”

If you have a feature of your program that

  • your client asks you to change several times
  • or simply that it can have different behaviors based on different inputs

then it is necessary to extract it from the main context and create one or more components that implement these different versions / behaviors.
Don’t be fooled to use the inheritance! In this case, in fact, inheritance cannot help you because there is the risk of having unwanted behavior performed.

Even the interfaces may not be sufficient because it forces you to write methods that are not used or to write the same method several times, duplicating the code.

Solution
Create a set of classes for each feature that tends to vary, where each class represents a possible behavior
Of course this set of classes implements the same interface.

Furthermore, following the principle
“Program with Interface and not with implementation”

to implement “unstable requirement” you will refer this interface in the main system.

In this way your client can change his mind whenever he wants, and you will be ready to please him and, perhaps, become his best friend or psychologist …

Architecture stack for 2019

When an IT consultant/architect/developer wakes up in the morning he knows that he has to study a new programming language before the fullstack runs away.

And that the new programming language tomorrow is already deprecated.

If you want to save your big fat neck today you have to know at least 80% of next languages.

Frontend layer

Angular and or React (better both, I know it’s not possible if you have also a private life).

If you have to choose today, for example, if you start programming now, I bet on React.
Rest WS as a client

Backend layer

Node.js and or Java (Spring it’s enough).
API Rest WS (Ok with Spring).

DB layer

MongoDb (or any nosql db) and or Oracle (or MySql or any sql db)

But there is good news. All Network layer is simple to manage now, thanks to different infrastructure-as-service like AWS, Firebase and Heroku

If you know all above things, well, you can continue sleep 30 minutes more!

Design pattern for chess masters

Today I played chess with a colleague, I made a couple of very good forks.
But he put me in trouble with a good opening.

Do you know what openings, forks and also nailing are in chess?

They are very precise schemes, they have the names (Gambetto di donna, Sicilian defense, English match, French defense,…), well-defined patterns, every good chess player must know in memory.

These chess pattern are grouped into different families like opening, finals, and so on.

They are very precise moves, which you can always repeat, in every game or several times in a game, to which names have been assigned and they bring a very precise benefits.

So, what tactics are for chess, then Design pattern are for OO Design:

  • a general design solution
  • to a repeatable situation 
  • with a description 
  • a very precise schema
  • and that you have to know
  • grouped in different families: creational, structural and behavioral

The general design situation means that, when you are designing an object oriented software, there is a well know way to do it for each type of component and layer.

Repeatable means that the situations are the same for each system you can design and so you can use again that model

With a description means that that situation has a name

Very precise schema means that there is a design model already ready to use and that you could adapt it to your component

You have to know means that you should study them so that you can apply in every situation

The different families are about the different type of design situations

  • Creational are abut the way in which objects are created
  • Structural pattern identify a simple way to realize relationships among entities
  • Behavioral provide solution for the better interaction between objects

Example of Creational pattern:

  • Abstract Factory pattern: a class requests the objects it requires from a factory object instead of creating the objects directly
  • Factory method pattern: centralize creation of an object of a specific type choosing one of several implementations
  • Builder pattern: separate the construction of a complex object from its representation so that the same construction process can create different representations
  • Dependency Injection pattern: a class accepts the objects it requires from an injector instead of creating the objects directly
  • Lazy initialization pattern: tactic of delaying the creation of an object, the calculation of a value, or some other expensive process until the first time it is needed
  • Object pool pattern: avoid expensive acquisition and release of resources by recycling objects that are no longer in use
  • Prototype pattern: used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects
  • Singleton pattern: restrict instantiation of a class to one object

Example of Structural pattern:

  • Adapter pattern: ‘adapts’ one interface for a class into one that a client expects
  • Bridge pattern: decouple an abstraction from its implementation so that the two can vary independently
  • Composite pattern: a tree structure of objects where every object has the same interface
  • Decorator pattern: add additional functionality to a class at runtime where subclassing would result in an exponential rise of new classes
  • Extensibility pattern: a.k.a. Framework – hide complex code behind a simple interface
  • Facade pattern: create a simplified interface of an existing interface to ease usage for common tasks
  • Flyweight pattern: a large quantity of objects share a common properties object to save space
  • Pipes and filters: a chain of processes where the output of each process is the input of the next
  • Proxy pattern: a class functioning as an interface to another thing

Example of Behavioral pattern:

  • Chain of responsibility pattern: Command objects are handled or passed on to other objects by logic-containing processing objects
  • Command pattern: Command objects encapsulate an action and its parameters
  • Interpreter pattern: Implement a specialized computer language to rapidly solve a specific set of problems
  • Iterator pattern: Iterators are used to access the elements of an aggregate object sequentially without exposing its underlying representation
  • Mediator pattern: Provides a unified interface to a set of interfaces in a subsystem
  • Memento pattern: Provides the ability to restore an object to its previous state (rollback)
  • Null object pattern: Designed to act as a default value of an object
  • Observer pattern: a.k.a. Publish/Subscribe or Event Listener. Objects register to observe an event that may be raised by another object
  • State pattern: A clean way for an object to partially change its type at runtime
  • Strategy pattern: Algorithms can be selected on the fly, using composition
  • Template method pattern: Describes the program skeleton of a program; algorithms can be selected on the fly, using inheritance
  • Visitor pattern: A way to separate an algorithm from an object
Weblogic Domain and Cluster


What is a domain?

A domain, in weblogic world, is a set of weblogic (WL) instances that can be managed by the same administration console.
That’s why they are call managed servers.
Each WL instance can run on the same machine of the administration server or remotely

What is a weblogic instance?

It is just an ip and port address where the single weblogic listen

Why to use (or at least to be aware)

If you have different weblogic servers that you need to manage (remotely for example) you can create a domain that includes them.
Or/And, if you need a cluster of instances then you must before add all cluster instances in a domain and then you can create your cluster
So you can have two types on WL instances in a domain: Standalone (which don’t belong to any cluster) and Clustered

How

In weblogic console, in Environment==> Servers you can add you weblogic instances. You have just to know the ip and port address of each weblogic instance you want to add in the domain

What is a cluster?

A cluster is a subset of a weblogic domain, where each WL instance of the cluster has the same goal: allow load balancing and fail over for the fantastic (same) applications they host.

Of course, as you manage a set of instance for the same application(s), when you deploy the application you do it just one time for all WL instance in the cluser, and the WebLogic Administration is in charge of update all instances in the cluster.
Just a thing good to know: all the WL in a cluster must have the same WL version

From a client point of view the cluster is transparent. The client doesn’t know how many WL instances there are behind that ip address

Why

Advantages of a cluster are the same of LoadBalancing and Failover.

Scalability (Load Balancing): The capacity of an application deployed on a WebLogic Server cluster can be increased dynamically to meet demand. You can add server instances to a cluster without interruption of service, the application continues to run without impact to clients and end users.


High-Availability (Failover): In a WebLogic Server cluster, application processing can continue when a server instance fails. You “cluster” application components by deploying them on multiple server instances in the cluster so, if a server instance on which a component is running fails, an other server instance on which that component is deployed can continue application processing.

How

You can manage WL instances for a cluster in just two steps:

  1. create the cluster (in Environment ==> clusters ==> new button)
  2. for each existing or new server you can choose a cluster

That’s it!

Debug remotely with Eclipse

To debug with eclipse to remote server follow below instructions

In the menu Run –> Debug configurations…

In the window popup select Remote Java Application

Right click, then select New

On the right a new fieldset appears

In the Project field browse the java project to attach

In the Connection Type field:

  • Select “Standard (Socket Attach)” – int the 99% of cases -, if you want to attach your eclipse to a server (which listen on a ip and port). In this case you should specify the IP/name and the port of the server you want to attach
  • Select “Standard (Socket Listen)”, if you want to be the host, listening just on a port (and on your ip). In this case you should just specify the port and the connection number you want to allow. Of course the machine is the same of eclispe running instance

The listening port, in both case (local and remote), must be preconfigured setting, as jvm parameters, the following:

-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=4000

  • The -XDebug parameter enables debugging
  • The -Xrunjdwp parameter loads the JPDA reference implementation of JDWP
  • Debugging, in the example, is enabled on port 4000

The JDWP protocol is the protocol used to debug with a remote debugger.

For example, in WebLogic server, to allow a debug socket listener, in the file “startWebLogic.cmd” add to the JAVA OPTIONS:

set JAVA_OPTIONS=-<others params> Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=4000,server=y,suspend=n

The -Xnoagent parameter disables the default sun.tools.debug debug agent

Just a little notice: if you want to debug clustered application, you have to attach the debug ide to all clustered servers, otherwise you need to be lucky to get the request to your debugged server

Curiosity: default debug port on weblogic 12.1.3 is 8453