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.
Related
What design patterns are commonly used or used together in developing e-commerce with microservices or multi-tier layer architecture? Let's say we will write the code using object-oriented language such as Java or .NET 5 just for an example and we develop the client app using a JavaScript framework.
Would the design patterns suggestion change if I choose to implement a microservices architecture?
There is a pattern called "Pattern: Microservice Architecture:"
Define an architecture that structures the application as a set of
loosely coupled, collaborating services. This approach corresponds to
the Y-axis of the Scale Cube. Each service is:
Highly maintainable and testable - enables rapid and frequent
development and deployment
Loosely coupled with other services -
enables a team to work independently the majority of time on their
service(s) without being impacted by changes to other services and
without affecting other services
Independently deployable - enables a
team to deploy their service without having to coordinate with other
teams
Capable of being developed by a small team - essential for high
productivity by avoiding the high communication head of large teams
Services communicate using either synchronous protocols such as
HTTP/REST or asynchronous protocols such as AMQP. Services can be
developed and deployed independently of one another. Each service has
its own database in order to be decoupled from other services. Data
consistency between services is maintained using the Saga pattern
To learn more about the nature of a service, please read this article.
And e-commerce application is considered as an example to apply pattern: Microservice Architecture.
So it is possible to create multiple services divided by entities or business domains:
customers
inventory
shipping
Then it is necessary provide the way of communication among services. It can be event streaming platform Kafka.
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.
How different is the recent buzzword of API/APIfication different from having a SOA based architecture?
Apart from the technical difference of APIs being REST-based web services and SOA being SOAP based webservices, are there any other benefit or advantage of this new buzzword API/APIfication?
...APIs being rest based WebServices and SoA being SOAP based Webservices
This is probably the least accurate definition of both terms I have ever heard.
I think the question you are trying to ask is "What is the difference between REST and SOAP web services?"
In this case there. Are. Many. Answers.
But, i was trying to understand the recent Buzzword of APIfication of
traditional/legacy Enterprise Apps
APIfication is meaningless. A google search of this term returns mixed results.
The concept seemed to be similar with SoA architecture style
API and SOA are unrelated concepts. Both terms have been around for years and their meaning has stayed fairly constant over time.
So, i was trying to clarify if i was missing anything
It's unlikely you're missing anything other than clarity about what exactly it is you want to ask.
My understanding of SOA architecture:
All code belongs to a service, regardless of what tier it runs in - whether it's UI, middle-tier or data access. It belongs to whichever service owns the data it operates on or displays.
Microservices never ever call each other. Instead, their UI's are composed together at runtime, and business processes that cross services boundaries are "emergent" rather than being orchestrated at a high level. The only communication that crosses service boundaries consists of events, and not data.
These events can be versioned, with newer versions extending older versions, so that the publisher can publish a new version of an event, while subscribers still receive the old version of the event (which decouples the services and prevents multiple services from having to be modified and deployed in lockstep.)
The "IT/Ops" service composes UI components from multiple services together at runtime to create the front-end interface of an application.
Since an API implies coupling between the provider and the consumer, API calls are only ever made within a service, not across service boundaries.
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.
At my company we are currently using the classic n-tier architecture using NHibernate as our persistence layer with fat objects. Seeing many issues with this pattern, such as full hydration of the object graph when entities are retrieved from the database we have been looking in to other alternatives.
In this process we have moved to a more scalable Command and Query architecture, and now we are looking into the viability of SOA.
In your experiences, what are the biggest advantages of SOA over n-tier. Have you encountered any major hurdles?
And advice and reading material would be helpful.
Besides scalability, SOA offers architectural flexibility. If you decide at some point to move your application from WebForms to Silverlight, both can take equal advantage of a well-designed SOA interface.
You can also decide at some point down the road to offer a new service that takes advantage of some of the features and/or data in your current offering. You just build a new application that is authorized to access your existing interface and away you go.
Loose coupling and governance.