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.
Related
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.
Intro
The company I work in (it is an intern-like position though, until I am done with university) recently implemented an automated warehouse solution, where goods are transported by means of autonomous shuttles. The basic functions of the shuttles are controlled by onboard electronics (microcontroller), routing through the warehouse racking is done by software solution which in turn communicates with our ERP solution. Effectively the ERP solution handles the whole warehousing.
Task
There are well documented processes for every of the four layers (operator who loads the the shuttles, shuttle itself, routing, ERP) individually. But since we kind of puzzled all four of them together to one solution (which was kind of new to all of the participating companies), there are only vague, on-the-flyish process descriptions involving all four layers available.
Now I have been tasked to come up with a solution to illustrate the processes at work.
Example
ERP signals goods in demand at assembly station A1
Warehouse operator looks at screen and starts loading boxes to be picked up by
shuttle
Warehouse operator puts in details into ERP, such as count/weight, box number,
...
Warehouse operator clears boxes for pick-up (by confirming inputs in ERP)
ERP generates transport order
ERP sends transport order to routing software
Routing software sends telegram to shuttle control
Shuttle control turns wheels and asks for directions to pick up boxes
...
Question
As mentioned, I have to graphically represent the kind of processes similar to the one shown in the (easy and not complete) example above. I need to incorporate the operator's actions as well as basic communication between shuttle, routing software and ERP.
Since I attended a course on BPMN at university it came to mind immediately. But now, after immersing myself into information about BPMN for several hours I still can't conclusively tell if BPMN helps my efforts or just further complicates the whole thing.
Is BPMN the right tool for my purpose?
Disclaimer
I am not a Business Analyst. I have looked at alternatives to BPMN (simple flowcharts, activity diagrams, ...) but they don't seem to fit.
Just putting together the existing processes for every respective layer yields no result, owing to the different and sometimes too detailed process descriptions.
Edit
The ERP is SAP ERP 6.0 EHP7 with integrated WMS component.
TL;DR: use the notation you would be implement process in, i.e. choose BPMS, not BPMN.
The notation itself means nothing unless it has proper tool for modelling and further process implementation aka BPMS. You can find dozens of comparisons (e.g. BPMN vs EPC or BPMN vs BPEL), however they won't help you unless you have clear understanding where and how you will be implement you modeled process.
Generally speaking, EPC is used for more high-level view of the process, whereas BPMN is utilized for more fine-grained view, where all technical details of communications between peers can be described. However, it depends.
I also recommend you to review this table
and answer the question to yourself whether your process changes (in)frequently or not, and whether you need separate BPM tool.
How I see it from your description: you have four participants (four layers), which are four lanes in BPMN terms, and they are collaborating/communicating with each other during the process. Generally speaking, this fits to BPMN application area, but personally I feel that you should stick your ERP tooling. I don't know which ERP you use, but every serious ERP solution includes tool for process customization. For example, SAP has Workflow,
which can widely enhance and extend existing processes within SAP. Probably, your ERP have it too.
Again, it's not clear which warehouse management system you use and if it is integrated to your ERP. It seems to be not, and it seems to be some old legacy system, because of which you start re-modelling the stuff. In this particular case it might me wiser to acquire special advanced warehouse management package (take a look at SAP's EWM features as an example) which can cover most of your requirements.
I have a system prototype, which I want to model in BPMN. That system has three layers: data layer, gui and business logic. Can I use these three layers names as BPMN swimlanes names instead of using actors or roles?
http://blog.goodelearning.com/bpmn/common-bpmn-modeling-mistakes-swimlanes/
Says swimlanes are for an organizational role (e.g. developer, analyst and manager).
As far as I understand it, the blog entry does not state that organizational roles cannot be IT systems. It even mentions content management system as one example for an organization (when discussing pools). Subsequently, a sub system of the content management system should be a perfectly valid candidate for a lane.
When it comes to technicalities, it's always good to refer to the BPMN specification. Regarding the usage of lanes, it states:
The meaning of the Lanes is up to the modeler. BPMN does not specify the usage of Lanes. (page 306, respectively 336 in PDF document)
So according to the specification, you can use these three layer names as BPMN swimlane names.
Well, your work might have finished a long ago, but you are mixing Architecture with BPMN (Process design).
Application mapping is not part of business process design and this is a common mistake done by people missing E2E purpose and scope of process modeling and how it integrates with other domains.
for Architecture you might need to use some other language more specific to it, say Archimate which handles this requirement very well and global standard for modeling architecture.
Business architecture/process architecture and process design are separate entities. we should try not to mix them.
All the best for current assignments.
I developing a 3 tier architecture for an MVC4 webapp + EntityFramwork5.
I want to keep separete the layer, so only DAL knows that I'm using EF, for example.
Actually I have a lot of classes to manage that:
DAL
Entity POCO
Entity DataContext : DbContext
Entity Repository
BL
Entity ViewModel
Entity Service(instantiate Entity Repository)
WEB
Entity Controllers (instantiate Entity Service)
This is working but is quite hard to mantain. I was thinking to remove the Entity Repository in DAL and use directly the DataContext (if I'm not wrong, after all DbContext has been desingned to be a Repository and a Unit of Work), but that will force me to add a reference to EntityFramework.dll in my BL. Is not a big issue, but I0m not sure it is the best choice.
Any advice?
(I hope I gave enough informations, if you need more, just ask)
You can use this this and this article.
An experienced Architect does not need to go through every single step in the book to get a reasonable design done for a small web
application. Such Architects can use their experience to speed up the
process. Since I have done similar web applications before and have
understood my deliverable, I am going to take the faster approach to
get the initial part of our DMS design done. That will hopefully
assist me to shorten the length of this article.
For those who do not have experience, let me briefly mention the general steps that involved in architecturing a software below...
Understand the initial customer requirement - Ask questions and do research to further elaborate the requirement
Define the process flow of the system preferably in visual (diagram) form. I usually draw a process-flow diagram here. In my
effort, I would try to define the manual version of the system first
and then would try to convert that into the automated version while
identifying the processes and their relations. This process-flow
diagram that we draw here can be used as the medium to validate the
captured requirements with the customer too.
Identify the software development model that suite your requirements
When the requirements are fully captured and defined before the design start, you can use the 'Water-Fall' model. But when the
requirements are undefined, a variant of 'Spiral' can be used to deal
with that.
When requirements are not defined, the system gets defined while it is being designed. In such cases, you need to keep adequate spaces
in respective modules, which later expansions are expected.
Decide what architecture to be used. In my case, to design our Document Management System (DMS), I will be using a combination of
ASP.NET MVC and Multitier Architecture (Three Tier Variant).
Analyze the system and identify its modules or sub systems.
Pick one sub system at a time and further analyze it and identify all granular level requirements belonging to that part of the systems.
Recognize the data entities and define the relationships among entities (Entity Relationship Diagram or ER Diagram). That can
followed by identifying the business entities (Some business entities
directly map with the classes of your system) and define the business
process flow.
Organized your entities. This is where you normalize your database, and decide what OOP concepts and design pattern to be used
etc.
Make your design consistent. Follow the same standards across all modules and layers. This includes streamlining the concepts (as an
example, if you have used two different design patterns in two
different modules to achieve the same goal, then pick the better
approach and use that in both the places), and conventions used in the
project.
Tuning the design is the last part of the process. In order to do this, you need to have a meeting with the project team. In that
meeting you need to present your design to your team and make them ask
questions about it. Take this as an opportunity to honestly evaluate/
adjust your design.
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.