Skip to main content

Open sourcing the Solutions Architecture Patterns

Solutions Architects (SAs) are the people who convert deep technical knowledge into a format that can be understood by both technical and non-technical people. They are the bridge between product engineers and salespeople. It is so strange that there is no common knowledge base (KB) that has been shared in the open-source community related to solutions architecture.
That was the motivation for me to build such a KB which can be reused by SAs regardless of which technology stack they are working with or promoting. I have started small an initiated a GitHub repository and started contributing solutions architecture patterns which I learn from other people and learn while I’m working as a SA. Today, I have released the 0.3 version of this repository with a set of new solutions architecture patterns. Here is the GitHub repository link for this repository.
The architecture patterns which are discussed here are not my own inventions. Rather, they are common patterns we found day in day out working as Solution Architects. The below mentioned diagram is a sample architecture pattern that is described in the repository.


Figure: Microgateway Multi Data Center Deployment Pattern

This repository is mainly divided into 2 categories. Those are,
  1. Vendor Neutral
  2. Vendor Specific
Vendor Neutral pattern category contains solutions architecture patterns which are not restricted to a specific vendor or technology stack. The architectures discussed here can be implemented with multiple vendors as well as with one vendor. But there are no special remarks on a specific vendor in most cases. There are some patterns that utilize specific technologies. But those are very rare.
Vendor Specific pattern category contains solutions architecture patterns that are specific to a given vendor or technology. These architecture are bound to respective vendors and their products. This is an area in which we are expecting some contributions from people working with these vendors since we have not worked with all the vendors mentioned in the repository.
We have started this project with the goal of building an open source community around solutions architecture discipline and a common ground where people can share their knowledge, ideas, and suggestions. This is still early stages and we have 65+ GH stars and 15+ GH forks as of this writing.
We would like to share an open invitation to Solutions Architects/ Engineers who works with enterprise software products and solutions to come and join with us to build a wider community around the technologies we build. You can send your contributions to the below GitHub repository link.

Comments

  1. Thanks for the Valuable information.Really useful information. Thank you so much for sharing. It will help everyone. Keep Post.
    Microservices Online Training
    Microservices Training in Hyderabad

    ReplyDelete

Post a Comment

Popular posts from this blog

How to protect your APIs with self contained access token (JWT) using WSO2 API Manager and WSO2 Identity Server

In a typical enterprise information system, there is a high chance that people will use different types of systems built by different vendors to implement certain types of functionalities. The APIs might be hosted in an API Manager developed by vendor A and the user management can be implemented using a different vendor (vendor B). In this type of a situation, one system will not be able to directly contact the other system but they want to use both systems in tandem. Self-contained access tokens are used in these types of situations where applications can get the token from one system and use that in another system to access protected resources. In this scenario, the second system does not need to make a contact to the first system over the network to validate the user information since the token is self-contained and it has relevant details about the user. This will improve the token processing time significantly since it completely removes the network interaction. The below fig...

WSO2 ESB creating a response for a "GET" request

When you are creating REST APIs with WSO2 ESB, you may need to send some response message back to the user when something goes wrong. In this kind of scenario, you can create a payload inside the ESB and send it back. For doing this, you can use the below configuration. <api xmlns=" http://ws.apache.org/ ns/synapse " name="LoopBackProxy" context="/loopback">    <resource methods="POST GET">       <inSequence>          <property name="NO_ENTITY_BODY" scope="axis2" action="remove"></property>          <log level="full"></log>          <payloadFactory media-type="xml">             <format>                <m:messageBeforeLoopBack xmlns:m=" http://services...

WSO2 ESB usage of get-property function

What are Properties? WSO2 has a huge set of mediators but property mediator is mostly used mediator for writing any proxy service or API. Property mediator is used to store any value or xml fragment temporarily during life cycle of a thread for any service or API. We can compare “Property” mediator with “Variable” in any other traditional programming languages (Like: C, C++, Java, .Net etc). There are few properties those are used/maintained by ESB itself and on the other hand few properties can be defined by users (programmers). In other words, we can say that properties can be define in below 2 categories: ESB Defined Properties User Defined Properties. These properties can be stored/defined in different scopes, like: Transport Synapse or Default Axis2 Registry System Operation Generally, these properties are read by get-properties() function. This function can be invoked with below 2 variations. get-property(String propertyName) get-property(String scop...