The Extensible Architecture Challenge – Part 2
Context: Sharpening the requirements for an extensible architecture
In my last post I described a set of requirements for an extensible architecture of a software system. As Robert mentioned, I was not very precise in what kind of system I had in mind. So these requirements wouldn’t be particularly useful for e.g. a computer game.
The system I talk about falls into the category of “enterprise information systems”. An example would be a bug tracking application, a requirements management tool or a project planning system. Characteristics of such systems include:
- It’s very data driven. Users care about the information they can manage. Most of the functionality is about how business data is produced, organized, interrelated, and presented. Users care much more about the “what” than the “how”. They want (or have to) to manage business information – functions such as “modify”, “import”, “create new”, etc. are just necessities.
- Users hate switching applications or even worse enter the same information several times into several systems. E.g. if there already is an application in place that contains address information of vendors (maybe an Excel Sheet on a network share), users would be annoyed if they would have to enter the same information into another system that requires a vendor list.
- The system has to be very responsive but not necessarily fast. Users don’t rapidly enter massive amount of information, nor are very complex operations common.
- The data that a user wants to work with at a given time is dependent on his/her current task and the role he or she is in. Users don’t want to handle or even see data that is not relevant for their task at hand. E.g. given a list of vendors, an accountant may want to see the account numbers, while a procurement persons is more interested in the total spend of this vendor.
- Users want the system to adapt to their information architecture and processes. Not only the data can be different from client to client but also the processes that govern the production and consumption of this data.
- An enterprise system does not typically have a massive number of users and the amount of data that needs to be handled is relatively low compared to large web applications.
- Enterprise systems are often very interlinked with other enterprise systems. Data needs to be maintained in several systems concurrently and synchronization is often manually.
- Security requirements are very high – data is often available only for few users and processes govern very strictly who should be able to read or modify which data.
The Extensible Architecture Challenge – Part 1
Context: Requirements for an extensible architecture
Introduction
Developing software that perfectly fits the needs of different clients is impossible. However it is possible to build a software architecture that is composed of many small pieces that can be stitched together for a single client to serve its needs. I’m going to write a series of posts that show one possible way to build such an architecture.
Known Requirements
By now I came up with a list of these technical user stories:
- As an integrator (e.g. a company that uses the system), I want to be able to access all system functionality via a REST based API, so that I can integrate it into my existing application landscape easily.
- As a user, I want to have a web based user interface to all system functionality, so that I can access the system from everywhere.
- As an operations guy, I want the backend tier (database + business logic) to reside on a different machine than the frontend, so that I can put a nice firewall in between.
- As a system integrator, I want to be able to leverage data from existing systems, so that users don’t have to enter the same data in more than one system.
- As a system integrator, I want to configure the systems functionality individually for each client, so that it fits the clients needs.
- As a developer, I want it to be very convenitend to extend the data, the behavior, and the look and feel of the system, so that I can shape it to the customers needs.
- As a user, I want the system to show only the data that I require for my processes, so that I don’t have to maintain information that I don’t really care about.
@Robert: Waiting for your comments 🙂
Homepage
Context: New homepage of Dieter Schewig
Yesterday the new homepage of Dieter Schewig (www.schewig-fotodesign.at) went live. The html template is based on the fantastic BlueTrip CSS framework which provided a very clean starting point. Typo3 was used as the backend system so that Dieter Schewig could manage the page content on his own – and I have less work with it. Only two extensions are used:
- TemplaVoila – for templating. The system is just hilarious to work with…
- Google Analytics – to count page visits.
The picture grid is rendered by a custom extension that randomly takes pictures from the filesystem of the selected category. I couldn’t find any existing extension that did exactly what was required; writing my own Typo3 extension was thanks to the “Kickstart” extension relatively painless.
Sharepoint Logical Architecture
Context: Sharepoint Logical Architecture (Web Application, Content Database, Site Collection)
Dave Wollerman wrote an interesting blog post and a great graphic about the logical architecture of Sharepoint. A quick summary:
- Farms host Web Applications
- One Web Application can have many Content Databases
- One Content Database can host several Site Collection’s
- The Central Administration and the SSP have each their own Web Application, Content Database and Site Collection
- Personal Sites are hosted in seperate site collections
Graphic referenced from the original blogpost.
Some important conclusio concerning using different site collections:
- If everything is within the same site collection you will result in a failed installation!
- Only site collections allow to establish a system of distributed administration.
MOSS Software Boundaries
Context: Planning the MOSS Infrastructure.
Plan for software boundaries (Office SharePoint Server)
This article provides information to help you understand the tested performance and capacity limits of Microsoft Office SharePoint Server 2007, provides information about the test environment and test results, and offers guidelines for acceptable performance. Use the information in this article to determine whether your planned deployment falls within acceptable performance and capacity limits.
Conclusion: Read the guide when you plan for a site that will have more than 2000 sites or site collections.
MOSS Administration Cheet Sheet
Context: Speed up your Sharepoint Administration with this cheat sheet.
Scolab posted a great cheat sheet, that shows where which configuration element (eg. User Profiles) is located in Sharepoint. In addition the chart shows what dependencies there are between the different services. Fantastic work!
MOSS Farm Inter-Server Communication
Context: Planning the MOSS Server Security and Firewall settings.
The article by Christoph Müller shows on a nice graphic how the Sharepoint servers in a typical MOSS farm communicate with each other. He also shows the required service and ports on the different server roles.
How to post source code to WordPress
Context: Displaying source code snippets in a wordpress Blog.
Just wrap the code with the following tags (use square brackets):
Some of the supported languages: csharp, css, html, java, jscript, sql, xml
Heilig und Schubert
Context: Archiving solutions for Sharepoint.
Heilig und Schubert provides an archiving solution for Sharepoint that can move Sharepoint Content to an archive based on a set of rules. Don’t know how it works exactly yet…
Derhackler's Blog 