To maximize organizational software throughput, an overall architecture must be contemplated and subsequent plans & periodic reviews put in place. It’s a process whose primary objectives must include
Continuous improvement to quantify & minimize long term operating cost
Organizations consist of sets of processes. A currently popular architectural pattern, MVC, scales reasonably well to enterprise level for encapsulating processes. Any software environment has three main tiered components:
| Model |
Controller |
View |
| Security |
Security |
Security |
Repository
- Source of Truth (SOT)
- Archive
- Warehouse
|
Rules |
On Demand |
| ORM |
Workflow |
Usability |
Security is a rare subcomponent where redundancy is not only accepted, it’s recommended.
Model – this tier has three subcomponents: Security, Repository & ORM. The Repository is the core raw material of an organization’s knowledgebase. Acute attention must be paid here because other components rely on it and inefficiencies at this level will have multiplicative effects on higher tiered components.
Repository maybe divided into three subcategories:
Currently acceptable and predominantly used mechanism for hosting SOT is to use relational database. Main objective here is to minimize data element redundancy. Relational database platforms offer a hierarchical process called normalization, based on well established mathematical model, whose usage guarantees reduction in data element duplication proportional to implementation depth, e.g., 2NF guarantees less redundancy than 1NF. It’s important to note that higher degree of normalization adds more structural complexity, which may in turn raise operating cost of this and subsequent tiers higher up by lowering performance and maintainability, thus a balance must be achieved. Subject to given environment, implementation to 3NF is widely accepted as a rule of thumb.
Archive is a repository subcomponent necessary to keep SOT agile & tuned. It hosts dated transactional material, which frees SOT to deal with static & chronologically relevant data. It structurally parallels SOT’s transactional entities. Various mechanisms exist to move data from SOT to Archive, such as scheduled SSIS package, etc.
Warehouse has a different objective, to de-normalize a set of data elements for consumer expediency, e.g., reporting, etc. and thus it must adhere to a couple of basic rules, data elements within this category must
- Solely rely on data elements within SOT as its data source
- Be non-transactional, e.g., read only
Log tracks sources of accessed data. It maybe as simple as a single entity written to by various data access triggers within other entities. Regardless of implementation, any Log record must be traceable back to specific entity along with timestamp & uniquely identifiable source. Logging mechanism is crucial for SOT but may also be implemented for Archive and/or Warehouse.
ORM is the objectified map of relational entities. It’s main objectives include seamless integration between data and code. Modern software applications often rely heavily on ORM for Rapid Application Development (RAD). An enterprise-wide ORM library would reduce duplication of efforts per application, but, it must be manually kept in sync with data repository and breaking changes would require adjustments to consumer components higher up the chain. Frequent changes to this layer points to either dynamic nature of the underlying business model or a lack of thorough understanding of it. Test Driven Development (TDD) approach would help changes in this layer avoid unintentionally breaking consumer applications.
There are a handful of reasonable security implementation options within the Model tier. One established option in windows environment is to funnel various levels of CRUD access via business process task specific windows AD groups, with sets of users as its members. In such implementation, new users need to be granted task specific access via their AD group membership while deactivating a user in AD automatically revokes their privileges.
Since changes in the Model tier has broad impact, it should be designed carefully from the start, involving specialists in data modeling to ensure well normalized SOT as well as relevant business model experts to ensure that entity model closely represents business model, so that technical changes are only necessary to accommodate business model changes, which is unavoidable regardless of implementation.
Controller – main objective of this component is to host & enforce rules and facilitate workflow & navigation. A controller library may encapsulate one or more Business Process Tasks and by it’s nature must be specific to one or more business processes. There are, however, ways to minimize code redundancy, for example, a base controller library might encapsulate workflow and rules engines, while business process specific controllers may use it to perform relevant tasks. Controller libraries may also be shared between different platforms, targeting a website & a smart phone application, for example. Important thing to note here is to have controllers emulate business processes and not bind too close a target platform.
Since controllers operate within an application’s context, security is often delegated to application host for authentication & authorization, but, security implementation at this tier is possible via Code Access Security (CAS), Filters, etc.
View – main objective of views are to provide visible access to data sets and ways to interact with it. It’s important to keep this tier as thin as possible, so that, targeting a new platform for an existing process could be as simple as creating a new view for the target platform.
Security at this tier is largely a matter of direct access, e.g., via installation, etc.
SingletonInstance
UnknownMessageReceived
CallbackContract
Technology Space 