Application taxonomies

A classification of software application can help you to think about an architecture and/or determine a reference architecture in your catalogue.
Multiple characteristics can be used to set up a taxonomy. These taxonomies can help you I think because it sets up a context for making a software architecture and the usage of reference architectures. Usually one classification criterion alone doesn’t fit the entire application . Multiple axes.

I think one of the main message would be : Don’t be fooled that one reference architecture can be used in all scenarios.

• Front-end technology
  o Windows (classic / touch screen)
  o Web-based (classic / Rich Internet client )
• Distribution
  o Desk-top
  o Mobile/PDA
  o Sever
  o Distributed
• Connected
  o On-line
  o Disconnected with on-line capabilities (smart client)
• Communication
  o Asynchronous
  o Synchronous
• Target
  o Consumer ( E-commerce, PDA)
  o Business (Traditional administrative data keeping or/and decision support)
  o Industry (MES, CIM, MRP, SCADA, real-time systems, PLC, Robotics)
  o Government E-government
  o Entertainment (Games)
• Connectivity
  o Internet
  o LAN
  o WAN
  o VPN
• Function
  o OLTP applications
  o Reporting applications ,Data warehouse, BI
  o Batch application
  o Service–oriented apps
  o Mobile device applications
  o Integration Applications ( ERP, Mainframe , etc)
  o Office applications and Office integration
  o Portals
  o System software
• Organisation boundaries
  o Departmental
  o organisation
• Usage pattern
  o Collaboration
  o Transactional, data keeping
  o Decision support
• Time pattern
  o Long running “transactions” (Workflow)
  o Short running business transactions
• Expected life-time
  o Short-term
  o Long term
• Business area
  o Medical
  o Financial
  o Government
  o Industry
  o Commerce
  o Etc
• Saas (Software as a Service ) software.
• Etc.

What do you think?

Best regards,

Alexander

Software architecture decisions

Hello,

I recently had to give a definition of what a software architecture is . Not always that easy because Software Architecture is a much loaded term. If you want some formal definitions what a software architecture is , I recommend reading the information on http://www.sei.cmu.edu/architecture/published_definitions.html#Modern

General tone in these definitions is that you need to make high-level decisions about the system you' re going to build;

• What style are you going to use? What is the structure?
• How is it going to function? How do structural components of the architecture work together?
• How does it meet the needs of all the stakeholders?
  
  

These high-level decisions have a high impact on the application. You can not change them easily if wanted or needed. Unless you’re prepared to put enough resources on the table.

In the bullets below I tried to sum up the different aspects of a software architecture. This list is not intended to be exhaustive.

• Windows front-end or web front-end ( Rich Internet clients)
• Layering, organization of code, separation of concerns,
• Representing “business objects” persisted in a database
• Exposed domain model or using Data transfer Objects / Presentation Model
• DataSets versus classic classes
• Organization of “back-end” logic
• Organization of “Presentation” logic
• Organization of “data-access” logic
• Distribution or not
• Remoting technology
• Authentication, authorization, Audit
• Data binding
• Synchronous / asynchronous
• ORM tools or raw ADO.NET
• Multi-language
• Exception handling versus status code
• Instrumentation /Logging
• Configuration
• Caching
• Database schema fixed or freely adaptable to need of design designs
• Long-running “transactions” (conversations)
• Reporting needs
• Validation rules placement (Attribute based, Intra object based, Inter object based)
• Etc.

It is important to take holistic approach towards the desicions. You will need to take some trade-offs and influencing criteria into account.

• Kind of application built (taxonomy)
• Tooling can constrain how you organize your application (code generators, frameworks, application building blocks, software factories ,etc)
• Availability/knowledge of people can constrain the “feasibility” of your architecture
• Process (top-down versus bottom up, behaviour-centric versus data-centric)
• External / internal regulation can influence your architecture (SOX, internal Audit rules
• Availability of reference architecture.
• Non-functional requirements
• Patterns
• Time-to-Market
• etc.

If I missing some points or you want to comment on this. Please feel free.

Best regards,

Alexander