On the Road to Success: defining the architecture and preparing the team
This article is a follow-up on the first post of the “On the Road to Success” series about planning and starting a project.
Defining a relevant and reliable architecture
The technical architecture document is probably the most important document. It should contain:
- Software architecture: with details of frameworks and standards you can use in your project
- Description of the target infrastructure, norms and protocols used
- Network infrastructure, components and zones
- Used flows and network protocols
- System quality attributes study (high availability, security, extensibility, fault tolerance, maintainability…)
- Deployment view and design
- Environments required: development, test, integration, pre-production and production
The final result of this document will be the deployment view (or physical view) of each environment. This view shows the components and the flows in one single schema. I want to insist that you have a pre-production environment, which is sometimes ignored. This environment should be an exact copy of your production environment. It is used for:
- Dry runs of releases to be executed by system administrators before doing the release on your production environment
- Reproducing and analyzing problems that have occurred on production
This environment should be managed the same as your production environment (in terms of security, deployment, administrators…), but it is not used by the end users.
This document is the most important deliverable before you develop any source code.
It is mainly used to answer the question: How will I guide my team members during the project. It is used by:
- Developers
- Testers
- Final users
- System administrators
What should you consider in writing this document? Here is a generic answer. I can’t answer this question in one blog post because it depends on many factors relating to your specific project, its infrastructure and the environments required.
You should consider:
- The clustering capability of eXo Platform
- The different flows between application servers, software and hardware load balancers, RDBMS, LDAP…
- The different system integrations that can be made (MS Exchange, Bonita, CMIS…)
- JBoss domain mode configuration
Building an effective team
Once your team has been trained as developers, you’ll have to ask a senior developer to prepare an eXo add-on to configure the platform before starting development.
This extension can include customizations such as:
- Site pages and layouts
- Default HTML web contents used in the site layout (e.g. your banners and footers)
- Site CSS files
- Enterprise directory integration configuration, if needed
- eXo Platform extension (create a new empty extension based on this project)
- Services that will be used for interactions between your system and eXo Platform IOC
- SSO activation configuration, if needed
I recommend that you use the Extension Generator add-on to generate your extension. It will use your UI modifications and you won’t need to write XML files manually.
You’ll have to prepare:
- Development environment that is shared with all your team for periodically integrating their work (weekly for example)
- Developer workstation: define the technical requirements, development IDE and configuration of each tool (and also the code formatting template)
- Source code management, continuous integration and artifacts repository systems
To make the development productive, I personally usually advise that each developer works on one portlet in standalone mode without integrating it inside the eXo Platform server. That’s why I choose, most of the time, to develop using the JSF 2 or Juzu frameworks. Using those frameworks, the switch from standalone to portal integration mode needs few changes and it can be automatized in the build process (using Maven profiles).
To be productive and deliver high-quality software, I recommend you use a good setup for:
- Unit tests
- Automatic functional tests (GUI test automation)
Using JRebel can save up to 25% of your development time (even more in some cases).
Next week, for the 3rd and last article of this series, we’ll have deeper look at deploying, monitoring and planning the future.
Join the eXo tribe by registering for the community and get updates, tutorials, support, and access to the Platform and add-on downloads!
Make the most out of eXo Platform 4
Register to the next weekly live demo session and get a complete overview of what you can do with eXo Platform 4. Reserve your seat now!