Architecture principle/model for limits of user access?

mhatch — Sat, 21 Oct 2006 20:55:00 GMT

Reflecting on a funcional review this week where the Operations GM kept talking about business intelligence and 'back-end SQL access' in the same breath, I realized that there needs to be a way to articulate what services users should be allowed to access. I was doing some reading tonight in Enterprise Architecture at Work and came across a layered application/services view that is similar to many whiteboard sessions I’m sure we’ve all done. One way to articulate a principle is achieved by describing a boundary at the ‘application services’ tier. In a transactional system we would not likely give ad-hoc access to users to the application objects or technical services, does it make sense to restrict Business Intelligence data access to the olap tier (assuming that olap fits at the level I've described in the diagram)? Here I've extended the layer diagram into transactional & BI spaces and rough Microsoft technology mappings - red line reflects the boundary.

Master & Transact		Business Intelligence
Users	Users	Users
Busines Services	Business Services	Reports
Workflow (WF, Biztalk)	Business Processes	Reporting (SSRS)
Application Services	Application Services	Query (MDX/XMLA)
Objects (.Net)	Application Components	Olap (SSAS)
Data Access (ADO)	Infrastructure Services	Data Access (T-SQL/SSIS)
Database (SQL Server)	Technical Infrastructure	Database (SQL Server)

mike hatch's blog : architecture

Architecture principle/model for limits of user access?