BPRFPC: An abstracted Architectural model for an End to end view

Author: Arindam Bhattacharya

Good and flexible architecture models are yet to exist while there are several good initiatives on developing some guiding principles to assist the community on Architectural best practices. 

However, this article is yet another attempt to simplify the architeutal ingradients at very high level so exploring in depth could be possible with the acquired knowledge. 

Architecture is a foundation for any technical know how's and a model is the engine of that foundation that orchestrates everything together. Below are the general components of the proposed model.

1. Business - Keeping business out, no architecture could be meaningful. Business is where the Strategies & Needs are defined and everything else needs to align with the Business. So, business is always the "WHO" context.

2. Product - The purpose of the Business is revenue through a Product. The product may constitute anything which is presented to the clients, even a service, or an application. So, the product is always a "WHAT" context and an architecture must reflect this context.

3. Resource- Starting from a simple object, it's properties, attributes, data, handlers, libraries, connectivity, storage, database, security etc. what constitute the Resource block. It covers everything within the logical boundary that fuels a product and becomes an enabler of the functionality that product delivers. So, this is a "WHICH" context that architecture must consider.

4. Framework- Framework is what that offers opportunities and it's a boundary on which a product, a model, a process or a compliance would be built on.

So, framework is a "WHERE" context that architecture must have a reference to. If there is no framework available, let's build one in a way so that it can be leveraged in similar type of requirements.

5. Process - Process defines how an engine will run day to day basis including all of its parts attached. So, it's a "HOW" context that architecture need to showcase. 

6. Compliance - Compliance is "being in control" by ensuring all organizational, global, standard, regulatory guidlines are followed across, policies are framed and enforced through controls and any violations are monitored, identified and reported. Compliance sits very near to business. So, it's an "WHY" context that an architecture must have reference to.

Everything else resides inside these blocks that  requires mapping with BPRFPC and further diving downwards.

To summarise, how this Architecture Model can be used?

A. Model 1,2 and 3 with the help of 4.

B. Customize or device 4 (If required)

C. Connect the dots at 5 and define

D. Identify, Validate and Measure at 6


Comments

Post a Comment

Popular posts from this blog

Secure Key Management- An important risk carrier

Author : Arindam Bhattacharya Password and key management are the 2 most important element of data security. As businesses have gained more reliance on data, the data stakeholders along with other application agents, both are slowly developing extended risks. While password weakness can impact the entire business services, weak key management can push towards major data breaches. As of now both are going by the standard technology and processes but there are unknown factors that may cause secure status to marginal.  While data stakeholders are nothing but the business and application users, residents are the application agents (please read as module responsible for authentication and authorization) those are native or integrated with the application. These residents can bring unprecedented risks by the way they are developed or integrated.  Keylogging can happen anywhere - especially in a software driven ecosystem  and it's becoming an open secret. As a user, one may deve...
Read more

Can Security issues be reduced with DevSecOps

Author- Arindam Bhattacharya DevSecOps merely cannot improve security unless there is a cultural shift. Security incidents/ issues could have been come down long before if there was proper attention given to the security processes. When we talk about any processes it is driven by both manual and automated processes.  While automation works best when the processes are made straight forward and desired outcome is known in advance but if this is not the case, intervention of manual process is what all needed. All gaps, incompleteness of the processes.are.because of such manual dependencies. DevOps pipelines helps to achive automation across the development and operational lifecycle but when security needs to be embedded, this require the same pipeline extended to security lifecycle as well. There are some practicality that works against this idea as because not all security processes can be invoked automatically.  For example - post a development module is set to form production,...
Read more