Architecture

Need uber-guru types who are willing to challenge the existing groupthink on design and architecture, especially on TDD and emergent design and pair programming anti-pattern” – job post at Monster.com 2/9/2010

I stumbled upon that quote following links on the role of the architect on an agile project. Maybe one important role of the architect is to help the team avoid groupthink.

Information Management recently sent around their pick of best IM blog articles of 2009.  Among them was Forrester’s James Kobelius’s reaction to Bill Inmon’s “incineration of a straw man concept that he refers to as ‘virtual data warehousing (DW).’”

Testing in large scale Business Intelligence (BI) projects face challenges in data quality assurance, metrics / aggregation rules verification, source to target mapping accuracy, the test cases to the requirements traceability, and anomalies in the dimensions to facts relationships. 

Oracle Business Intelligence Enterprise Edition (OBIEE) is a BI tool that addresses quite a few of these challenges by the nature of the product's growth strategy.  As Gartner puts it, "70 functional and industry-specific packaged BI applications built on the Oracle BI Enterprise Edition Platform attests to Oracle's understanding of how to leverage the market interest in domain-specific and prepackaged solutions as a growth driver for its platform."  Customers who buy OBIEE typically also buy a relevant packaged solution.

I presented a talk called "Enterprise Data Validation" at the Hampton Road .NET User Group this evening. The premise was simple. Data validation needs to happen in all the tiers of a modern application but the validation rules should be defined only once to avoid synchronization errors. In this talk, I showed how to extend SQL Server using extended properties to store regular expressions for data validation as column metadata. I also showed how to add a regular expression matcher to SQL Server using the SQL CLR and how to add check constraints to invoke the regular expression parser. Then I built a WCF service to query the validation metadata to make it available in other application tiers. I quickly assembled WCF service host and client showed how you could bring all of the elements together to create a working Enterprise Validation solution.

Download the SQL Scripts (20.06 kb)

After being involved with recent Alfresco-based enterprise portals, Iʼve begun reflecting on best practices in regards to integration with the popular open-source CMS.  This article describes some learnings on integrating Alfrescoʼs Document Management (DM) and Web Content Management (WCM) repositories with an enterprise portal.

When iterating over a sequence of numbers in Python, the range() function is commonly used. However, the implementation of the range() function in Python 2.x instantiates each element in the sequence before the iteration begins. This is really costly from both memory and CPU perspectives when the desired range of numbers is large. Consider using the xrange() function instead which implements a Python generator to yield each number in the sequence as needed. Using xrange() instead of range() for large iterations can have a big, positive impact on your code. For example, in an application I was working on recently, replacing range() calls with xrange() boosted my performance from ~900,000 transactions per second to over 3,000,000. In Python 3.x, the range() function is supposed to be implemented as a generator but I haven't tested that to be true yet. Let me know if you have.

I spoke at the Charlottesville .NET User Group this week and at the Raleigh Code Camp. I cheated and did the same presentation to both groups. Call me lazy but, in the middle of planning our own Code Camp in Richmond, I really didn't want to prepare two separate talks. I did a talk back at CodeStock 2009 on a similar topic back in June 2009 but it's evolved a lot since then based on my own growth and understanding. You can find the code and slides below.

We are probably all familiar with access control as an IT architecture requirement.  It is one of the most common security features that we build into enterprise applications.  Access control allows authorized individuals to use the menu options, screens, reports and other features of a system that they need to do their jobs, while it keeps out the bad guys who might want to misuse a system.  For the business owner of an application, access control is all about knowing who can get to what, and who can't.  But for the compliance auditor, access control is more about knowing who authorizes whom to get to what, and why.

You see, compliance auditing is all about verifying controls.  A control is simply a procedural or technical "checkpoint" that reduces risk to an organization.  For instance, when a user requests access to a menu option within an application, that request should go to a manager for approval.  This is a control that ensures that the user needs the access that they have requested.  After the manager has approved the request, it should go to a different person to be provisioned.  This is another control.  It ensures that the manager can't give themselves or someone else unlimited access to the system without anyone else knowing about it.  The compliance auditor is interested in seeing that all of these controls are in place and are working properly. 

To be sure that the controls are in place, the auditor is going to want to see a documented process for access control that includes all of the applicable steps in provisioning a user to a system feature, and also the process for de-provisioning the user, should they leave or change job roles.  The written process will need to call out its control points, and it should be readily evident to the auditor that these controls cannot be easily circumvented.  The auditor is also going to want to see evidence that the written process is being followed each and every time. This is where the system architecture comes in to play.

To be easily audited for compliance, the access control features of a system have to be very transparent.  In other words, it should be easy for the auditor to figure out who has access to what features of the system.  This is fairly easy to accomplish provided the system uses RBAC (roles based access control) or some other well-known access control methodology.  For instance, RBAC maps each user to one or more roles, then maps those roles to one or more system features (It may also employ groups to aggregate users into roles).  The auditor is going to want to see that map of Users>(groups)>Roles>Features in plain language, and may want to see how the system implements the map at a technical level (although in practice few auditors are technical enough to discern whether the map is fully implemented in the code).  The auditor may even ask for a demonstration that the RBAC schema works, which may require a penetration test using automated tools or brute force.

The other architectural compliance feature that a system may need is a robust logging mechanism to track access control changes.  The auditor is going to want to see a cradle to grave audit trail that starts with the end-user request for access to the system, and carries through the approval process and the changes made to the access control map within the system.  This audit trail can be implemented piece-meal using e-mails trails, system logs, and the like.  This is probably the most common way for legacy systems to implement the process.  However, a much more robust and friendly way to implement the process is to use an enterprise RBAC environment such as Microsoft Active Directory or IBM Tivoli and a provisioning tool such as Courion that automatically tracks and logs all account provisioning activities.  This will require your application to have a service interface to the RBAC infrastructure, which may sound complex, and it is.  However, the one-time implementation costs will probably be far outweighed by the repeated administrative savings every time a user is provisioned, not to mention every time the auditors come to town.  Of course, using a service interface for access control will raise concerns about system performance and the in-transit security of provisioning requests, but these concerns can be readily addressed in the architecture as well.

And finally, don't forget that at the enterprise level the provisioning mechanism will need to be connected to the Human Resources system, so that every employee addition, deletion, or organizational move will trigger the provisioning system to either take action, or at the very least to notify someone that action needs to be taken.  This is another service interface, and will probaby require some glue code to make it work properly.

This is just the tip of the iceburg with respect to compliance and access control.  But I hope it has given you something to think about.  Next time, I will talk about data integrity and SOX compliance, which has made the news on more than a few occasions in the last couple of years.