I am trying to understand the core concepts of TOGAF 9.
No matter how often I read the explanation in the TOGAF manual, I don't understand the differences and the relationship between the Enterprise Continuum and the Architecture Repository.
Some quotes from the documentation:
Enterprise Continuum
"The simplest way of thinking of the Enterprise Continuum is as a view of the repository of all the architecture assets. It can contain architecture descriptions, models, building blocks, patterns, viewpoints, and other artifacts"
"The Enterprise Continuum provides a valuable context for understanding architectural models: it shows building blocks and
their relationships to each other, and the constraints and requirements on a cycle of architecture development."
(pages 565 and 48)
Architecture Repository
"This section of TOGAF provides a structural framework for an Architecture Repository that allows an enterprise to distinguish between different types of architectural assets that exist at different levels of abstraction in the organization."
(page 593)
Assumptions
The samples/template-package of TOGAF contains a word document "TOGAF 9 Template - Architecture Repository.doc", so
1) I think of the architecture repository as a large document, containing all outputs of all projects related to the architecture.
2) The enterprise continuum is another document classifying the contents of the architecture repository from foundation architecture to organization architecture and providing information about the relationship between these objects.
What is the difference/relationship between the enterprise continuum and the architecture repository?
The architecture repository is the content - all your designs, policies, frameworks etc.
The continuum is the means by which you classify them. It's not just where something is in terms of foundation->organisation. It covers everything, so as per above you will have classifications of 3rd party frameworks, business principles, Technical Standards, all those things too that are present in your enterprise.
Within the EC exists the Architecture Continuum and the Solutions Continuum. THis is where you classify your ABB's and SBB's according to the Foundation, CSA, Industry, and Organisation tiers.
Enterprise Continuum = Architecture Continuum + Solution Continuum
What is Continuum
Continuum models explain variation as involving a gradual quantitative transition without abrupt changes or discontinuities
The Enterprise Continuum provides a consistent language to communicate the differences between architectures so that Architectures and Solutions can be re-used, Also EC is
A view of the Architecture Repository
Methods for classifying architecture and solution artifacts
Re-use a industry standard solution where ever its possible rather than re-inventing a wheel , in other words a Telecom industry has a well established billing software and solution for both its retail , inter connect and value based services , use those solutions ( softwares ) rather than writing your own home grown software solution, this helps in business continuity as you are re-using industry standard experience rather than re engineering your own solution.
Some times even the language specific to industry standard counts a lot for example you talk of inter connect billing people in telecom domain understand it , where as if you invent new words to coin the same you would end up confusing the stake holders / partners associated with
Generalize a Specific Solution or Customize a Generic Solution based on External factors that influence Architecture Context
1. Architecture Continuum
Architectural Continuum = Foundation Architecture + Common System Architecture + Industry Architecture + Organization Architecture
where
Foundation Architecture provides direction and strategies for products and services, Very High level, Generic,
Common System Architecture create an architecture useful for building common and reusable solutions across a wide number of relevant domains, Some of the examples are Security Architecture, Email Architecture and Network Architecture
Industry Architecture is more Industry Specific , for example telecom industry might follow some standards no matter which operator operates in which country, Active Store Arch for Retail Industry, eTOM for Telecom Industry
Organization Architecture is more related to Specific Enterprise or Organization, Tailored for Specific Org Needs, Each Business Divisions might have different needs , and each Divisions might have different Org Specific Architecture. They are more requirement specific,
2. Solutions Continuum
Solution Continuum = Products and Services + System Solutions + Industry Solution + Organization Solution
example
Products : Need to be procured based on Approval chain
Services : Need to be top class including In Person Training with Course Material
System Solutions : Only Certified and Branded Systems need to be implemented
Industry Solutions : Procure Re-usable components from Industry leaders if it is better choice than to develop your own
Organization Solutions : Implementation of the EnterpriseArchitecture that provides therequired business functions
All working together in Enterprise Continuum
Architecture Repository is the list of Architecture Artifacts.
Enterprise Continuum shows your way how to participate in the Enterprise life - how and when to update Architecture Repository for example.
The following description was helpful in differentiating the framework from the repository.
From TOGAF 8 definition which I find clearer than TOGAF 9 definition stated below.
The practical implementation of the Enterprise Continuum will often
take the form of a repository that includes reference architectures,
models, and patterns that have been accepted for use within the
enterprise, and actual architectural work done previously within the
enterprise. The architect would seek to re-use as much as possible
from the Enterprise Continuum that was relevant to the project at
hand. (In addition to the collection of architecture source material,
the repository would also contain architecture development
work-in-progress.)
The criteria for including source materials in an organization's
Enterprise Continuum will typically form part of the organization's IT
governance process.
The Enterprise Continuum is thus a framework (a
"framework-within-a-framework") for categorizing architectural source
material - both the contents of the architecture working repository,
and the set of relevant, available reference models in the industry.
To Answer your question in layman terms
Architecture repository is a large document, containing all outputs of all projects related to the architecture.
Enterprise continuum is another document classifying the contents of the architecture repository evolving from the most basic foundation architecture to organization architecture (from basic to application specific) and providing information about the relationship between these objects.
Note That: Architecture Continuum inter-relating solutions continuum as well
The Enterprise Continuum is the way HOW you sort your architecture documents. The following pictures illustrates the Enterprise Continuum concept:
How does the Enterprise Continuum work?
The Architecture repository is the actual collection of architecture documents of an enterprise. It is organized with the structure that the Enterprise Continuum suggests.
Other TOGAF concepts are explained here: https://www.digitalroadmap.management/blog/2019/1/13/what-is-togaf
Architecture Continuum provides a framework or methods for classifying Architectural assets in a manner that makes accessing and communicating them to various stakeholders easy and understandable. The issue here is that Architectural Artifacts are build from various models, and this is bound to come up with assets descriptions with different notations, which is bound to make communication and understanding difficult. So to me its more of HOW Architectural Artifacts are stored in the Architecture Landscape.
On the other hand Architecture Repository focuses at WHERE physically the Architectural artifacts/Assets are stored and to some extend WHAT aspects of it are stored.
From Open Group / Core concepts (http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap02.html#tag_02_06): The Enterprise Continuum is a view of the Architecture Repository (emphasis added).
Whereas the repository is the store of artifacts, organised in a specific manner.
Here is my 2 cents worth.
Enterprise Continuum is the collection of documents not just within architecture framework but can be used for the architecture to improve efficiency, speed and accuracy. The contents are stored in Enterprise Repository which will also store Architecture Repository
Architecture repository is specific to the project at hand which is under the complete control of EAs. This includes artificats and deliverables from the ADM cycle.
First of all, Enterprise Continuum is not a physical repository like Architecture Repository. It's a kind of a report on the underlying physical architectural assets classified according to your convenience. One way to do is to classify them as Foundation, Common System, Industry and Org Specific. EC is like querying the underling architecture repository in an Oracle database for example.
Related
I worked at a company that uses Model View Controller architecture, it's a big project that didn't have unit tests because the code is tightly coupled.
So when I saw this, I started my research and came across several terms, like Domain-centric and Data-centric Architectures.
I recently started reading Uncle Bob's "Clean Architecture" and I'm confused...
I have two questions:
Is MVC architecture good for small projects?
Is Clean Architecture a monolithic architecture?
AND:
Can you advise me on some introductory books related to Software Architecture?
Sorry about my English.
MVC architecture is good even for small projects because it reduces coupling and ensures high cohesion
I don't think Clean architecture is a monolithic architecture because it can also be a micro-service architecture: https://blog.cleancoder.com/uncle-bob/2014/10/01/CleanMicroserviceArchitecture.html
For Software Architecture resources you could check out online courses through sites such as Udemy, or reference a textbook such as Software Architecture in Practice: https://www.amazon.ca/Software-Architecture-Practice-3rd-Bass/dp/0321815734
When it comes to design in general and architecture in particular it is always a matter of trade-offs so depending on the specifics MVC can be good for small projects and CLEAN can be used in microservices.
Generally speaking, MVC was born in the 70s and while it revolutionized UI te two way communications in incurs creates complexity, some coupling to the backend apis etc. There are many other approaches today like for example encapsulated component in svelte
As for CLEAN - in my opinion it makes little sense for anything but monolithic applications since there's a lot of overhead in each microservice and if you model each entity in a separate service you'd just end up with a distributed monolith
What is preferrable project internal structure for designing API based task.
1) Application will create API which will be acting as consumer and provider both 2) As a consumer it will integrate with multiple systems 3) Integration Systems can be SOAP based or SOA based
To answer the question which structure should the project have, you should define first:
if project is oriented on business requirements and they are being changed quite often, then it's SOA based architecture. The main difference between Service-Oriented (SOA) and Service-Based Architecture is that SOA had a "message-bus" layer, which translates business requirements to existing architecture. Service-Oriented architecture has similar topology to Microservice architecture, but services are more task/project oriented, not as small as in microservice;
if project has clear vision how API should look like and can define as a part of a tech specification, then first create an API, and then build other systems around;
second option you mentioned (As a consumer it will integrate with multiple systems) depends on project's needs, hard to say without knowing tech specifications.
According to TOGAF specification, the main domains / division of concerns are:
Business Architecture
Data Architecture
Application Architecture
Technology Architecture
According to the specification, the Enterprise Repository should hold all information.
I have this information:
How it works the company in terms of business model
How it works the application in terms of functional features
How the application is implemented and deployed
How can I map this data according to the TOGAF big picture?
App architecture description --> Architecture Landscape ?
App components description --> Solutions Repository ?
App functional description --> Architecture Capability ?
App deployment info --> ¿?
Business model --> ¿?
Update 08/11/2018
Some questions I have:
Where can I put company info like company structure, people, teams, etc?
Where can I put business info like products and services offered by company, how pricing is calculated? what it means "X thing" for the business?
Where should I put ongoing assessments? and where should I put once it's put in production?
Where should I put a general glossary of terms?
Where should I put development guides? like list of environments, IPs, delivery workflow, jira workflow, etc?
Where should I put service API definitions?
You are trying to mix Solution Architecture and Enterprise Architecture, that's probably why it seems confusing.
TOGAF is about enterprise architecture - big picture stuff, as you correctly pointed out. Information about a concrete app on the other hand is more of a solution architecture concern. Of course, one could argue that you can describe enterprise architecture as detailed as you need, but that's not the point.
Answering your original question, though: it seems like app information (architecture description, components description, functional description) you have should be stored in Architecture Repository as Solution Building Blocks. I'd recommend addressing them as part of Baseline Application Architecture and Baseline Technology Architecture description, during Phase C and Phase D.
Then again, you should first carefully consider wether you really need level of detail this high.
P.S. if you provide a bit more context on what you are trying to achieve, I'd probably be able to give you more specific advice
Update 11/11/2018
Where can I put company info like company structure, people, teams, etc?
It depends. Company structure should be stored in Baseline/Target Business Architecture as part of Organization structure model. Here's a definition from TOGAF:
"Organization structure: document the organization structure, identifying business locations and relating them to organizational units."
It is also one of the inputs - Organizational Model for Enterprise Architecture (see Part IV, 36.2.16 of TOGAF spec).
Where can I put business info like products and services offered by company, how pricing is calculated? what it means "X thing" for the business?
It is also a part of Business Architecture, here's a whole list from TOGAF spec:
Organization structure - identifying business locations and relating them to organizational units
Business goals and objectives - for the enterprise and each organizational unit
Business functions - a detailed, recursive step involving successive decomposition of major functional areas into sub-functions
Business services - the services that the enterprise and each enterprise unit provides to its customers, both internally and externally
Business processes, including measures and deliverables
Business roles, including development and modification of skills requirements
Business data model
Correlation of organization and functions - relate business functions to organizational units in the form of a matrix report
Where should I put ongoing assessments? and where should I put once it's put in production?
There's a standard pattern in TOGAF:
Assess current situation and write it down as Baseline Architecture
Create a vision and write it down as Target Architecture
Work towards Target Architecure and update Baseline Architecture as you go
So, in the end, your baseline should become equal to target and now it's your new baseline for the next ADM cycle.
Where should I put a general glossary of terms?
It's usually done as soon as possible during tailoring TOGAF to your enterprise - Preliminary Phase of the ADM cycle (see Part IV, 36.2.21 of TOGAF spec).
Where should I put development guides? like list of environments, IPs, delivery workflow, jira workflow, etc?
Developments guides, jira workflow and other project management stuff is not usually of a direct concern of TOGAF. It should be definitely be aware of it, enterprise architect might even consult on this matter. Only one thing comes to mind in terms of project management - roadmaps, they are written down and updated as needed during virtually all the phases.
Environments, IPs and other infrastructure information is usually worked on during Phase D, mainly as part of technology architecture models and specifications.
Where should I put service API definitions?
Again, you should carefully consider if you need this level of detail, but it seems appropriate to address it in Phase C (Applications Architecture). One of the steps is defining a model (it's advised by TOGAF to find reference in your industry), which may include API definitions. It's usually enough to address a more abstract Applications Interoperability in terms of the enterprise.
Very important point: TOGAF is just a framework, you can tailor it as you see fit for your current enterprise, just don't forget to document it. You should also remember that it's not just a set of tools, but also a set of expectations, glossary of terms and guidelines, so a new architect wouldn't need to learn everything from the ground up in each new enterprise he works at. As it always goes - you have to find a proper balance point.
I know that frameworks provide useful interfaces and classes that save a lot of time in implementation phase, so my question is:
Should the framework interfaces and classes be included in my project's class
diagram design or not?
and if it is,
Does this affect the reusability of the design if I decided to change
the framework in the future?
UML diagrams are intended to be read by different interest groups. Business likes to see requirements, use cases and activities. Architects/testers need that as a basis to develop/test the system. And the results produced by the architects (static and behavioral class diagrams) are meant to be read by programmers. Each reader group has a focus on certain parts but will eventually peek more or less into border areas (from their perspective).
So to answer your question: yes, frameworks shall be part of the model. Architects should pay attention as to how to cut the system. Frameworks should be designed with a different (broader) scope. So eventually you have frameworks that will be used only partially in a system. Or a system has a potential for a framework and it will be designed to be easily decoupled. Of course, this is a tricky task and architects need lots of experience to fulfill all the needs that come from business and eventually other stakeholders.
No, theoretically it shouldn't, but you're also free to do so.
As stated by the authors of UML: Rumbaugh, Jacobson, Booch
on The Unified Modeling Language Reference Manual at page 25
Across implementation languages and platforms. The UML is intended to be usable for systems implemented in various implementation languages and platforms, including programming languages, databases, 4GLs, organization documents, firmware, and so on. The front-end work should be identical or similar in all cases, while the back-end work will differ somewhat for each medium.
I am beginning in UML and software analyse and i do not understand how UML and diagrams can influence coding and software architecture while we can directly build the code and its data base without diagrams.
I read lot of tutorials abouat the subject but not enough to understand the utility of UML in coding.
I understand everey diagram and its role. That is not my problem but i do not yet understand their roles after the analyse and design phase.
So what is the role of UML in coding phase of a software ?
Thank you.
The comment by #xmojmr already puts it right. UML creates a model (hence the M in UML) of a system. A model reduces information of a system to a level so it is a) manageable and b) complete. Human brains are not computers and you need a means of communication what the system is all about. You can do that as pure code, as paper document and as UML model. A combination of all is not uncommon. As long as you have tiny systems you can live with pur code and tools like Doxygen. But once it starts getting complex you need some handles. UML offers these to end users, architects, testers, developers, managers, etc. Along with UML you will also need a methodology. UML delivers the syntax how to document a system. But you need some structure above to write a nice novel.
UML-based models play an essential role for coding/implementing a software system in model-based (or model-driven) development. The basic idea is that you start making a model of your problem domain (the domain model), then you derive from it a platform-independent design model, which can be transformed into platform-specific implementation models (e.g. for Java- or C#-based platforms) that are finally encoded in the target languages.
The most prominent part of model-based development is the encoding of model classes (forming the model layer in an MVC architecture for apps) based on a data model (a UML class model) that has been derived from an information design model, which was obtained from a domain information model (where all these information/data models are UML class models).
You can find an instructive example of model-based development in my tutorial book Engineering Front-End Web Apps with Plain JavaScript.
This one is in my point of view a duplicate of that other question. It can't be flagged because there is no accepted answer. The related question on meta stackexchange does not provide a clear solution to that situation.
I think my personal answer was relevant and is applicable to the current question.
To be synthetic, Martin Fowler considers current uses of UML. I think he describe the current practices. Perhaps should these evolve ?
Perhaps would the initial question be the right place to discuss ?