reference architecture

Port Numbers

I have been working on a distributed application and needed to assign some port numbers.

This link was very helpful - http://www.iana.org/assignments/port-numbers.

Reuse Practices

Here are some key software development reuse practices:

• strong software architecture that provides framework for reuse activities
• software development process that promotes and controls reuse
• reuse more than just code; reuse at the architectural level
• practice domain engineering; develop reusable components at the domain level
• integrate reuse through all of the life cycle activities and the management of those activities
• use software tools that support reuse; modern IDEs along with supporting knowledge bases are very useful.
• organizational structure that facilitates partnering across project boundaries

Reuse can occur at many levels. Some of the levels, starting at the lowest level and working up are:

• code fragment (cut and past reusability)
• subroutine or function
• object (data and methods)
• component
• architecture
• business patterns
• packaged application frameworks

Effectively reusability doesn't just happen. It is a planned event that takes time and resources. A separate domain engineering and knowledge base is required to promote and push its use throughout the organization.

The problem with reusability is that it usually isn't cost effective until a component has been reused (with very little analysis or modification) 5 or 6 times. Designing components for reusability slows down the current design and implementation process and requires a domain engineering/knowledge sharing organization to support and carry-on the reuse efforts.

Reuse is most effective when it is tied to business or technical patterns. The lower the level that reuse occurs the smaller its payback. This is because the first four (4) levels that I listed above only affect the implementation or coding cycle. Architectural and business patterns and customized packaged applications cut across many more of the software development lifecycle (SDLC) cycles and therefore have a larger impact.

Why Every Brand Needs an Open API for Developers

 

Why Every Brand Needs an Open API for Developers

The TIBCO ESB/SOA Platform

The TIBCO ESB/SOA Platform - Part 1

The TIBCO ESB/SOA Platform - Part 2

SOA Design Principles

Thomas Erl uses the following eight (8) principles to discuss SOA design:

• Service Contracts
• Service Coupling
• Service Abstraction
• Service Reusability
• Service Autonomy
• Service Statelessness
• Service Discoverability
• Service Composibility

 

Simplicity versus Complexity

[Note: Originally posted on "improving outcomes blog" on 2Mar2010.]

Simple is hard.

It is much easier to do things the complex way. It takes very little thought about what you are doing or how you are doing it if you don't care about the complexity of the process or the resulting product.

As Abraham Lincoln said, “I'm sorry I wrote such a long letter. I did not have the time to write a short one.”

Mark Twain is also quoted as saying, "I didn't have time to write a short letter, so I wrote a long one instead." [update 8/23/10]

So, if complex is easier and faster, and simple is harder and takes longer - why do I want to simplify?

As I have discussed in previous posts - it comes down to the difference between ad-hoc and repeated-use processes and products. The difference between designing/optimizing and executing/maintaining.

If a process is performed just once or if there is only a single implementation of a product then there is little benefit to simplicity. These are truly ad-hoc processes and products.

For everything else, the answer is quality. Quality attributes like functionality, reliability, availability, usability, efficiency, maintainability, and extensibility.

It is hard to get the results you want on a reliable and repeatable basis using complex processes and products. Complex processes and products have more failure points and break down more often than simple ones. And, when they break down it is difficult to find the root cause of the error and fix them. It is also very hard to learn complex processes and products and become efficient using them. Finally, complex processes and products are difficult to modify or extend to support changing needs.

Where does complexity come from? It can creep into your processes and products in many ways. A few ways are:

• Converting ad-hoc processes to organizational processes.

• Designing without the real end-user in mind.

• Layering governance processes onto organizational processes. This is also know as the bureaucracy factor.

• Poor implementation, including training, of organization processes.

Two key approaches to remove complexity are:

• Design all processes and products with the focus on the end-user. Understand the needs of the end-user and meet those needs as simply as possible.

• Only add tasks, features, and functionality to your process and products that are absolutely required. Also, remove any that are no longer required. Leaving unnecessary bloat in your processes and products are a big cause of complexity.

References:

1. Harvard Business Publishing Webcast - Take Complexity Out of Your Company, with Ron Ashkenas, author or Simply Effective.

Evolving Database Design

The concept of the "golden" and immutable database schema makes me crazy.

Agile methodologies, like SCRUM, have been adopted by many development groups to account for the fact that a perfect and unchangeable requirements specification will never exist before programming begins.

However, a big impedance mismatch will threaten your efforts if the application's database schema is under the control of a separate DBA group that is following a traditional waterfall methodology. (Note that I am talking about the application's database schema and not enterprise data store schemas.)

Academically I have seen and discussed many different ways of dealing with the issues associated with database changes. Martin Fowler and Pramod Sadalage discuss many of these issues in "Evolutionary Database Design".

In practice I have favored individual developer database instances with data architecture/DBA review. Just as solution architects don't babysit each system design change I don't think that data architects or DBAs should either. Any issues related to a design change can be dealt with using regular reviews and subsequent re-factoring.

In this practice the database schema and build scripts are part of the solution. To get a local database instance to work with the developer just gets the latest solution from source control and runs the DB build script. If they need to make changes to the DB then these changes are made and tested locally by the developer and then finally checked into source control for the rest of the team. The developer who makes the DB changes is also responsible for making sure that any required code changes are also checked in at the same time. A communication mechanism needs to be put into place so that the rest of the team knows that they will need to update their database at their next integration point (i.e. source code get latest).

Depending upon the phase of development, changes may be made to the original schema and everyone will have to rebuild their database or changes will be implemented as alter scripts and everyone will only have to update their database. Once the system goes to production all modifications will need to be implemented as alter scripts.

Microsoft TechEd Architecture Presentations

Architecture presentations from Microsoft TechEd 2010 are available.

The presentation on "Command/Query Responsibility Segregation" is especially good.

Although not part of the architecture presentations I also recommend "Using Microsoft BizTalk ESB Toolkit and Integration Patterns to Improve Business Agility".

Health Level 7 (HL7) Resource

InterfaceWare provides a good resource for the HL7 Standard v2.6.

Using this resource you can browse through the entire v2.6 of the HL7 standard. This includes messages, segments, and fields.

Windows Azure Application Security

Microsoft has released "Security Best Practices for Developing Windows Azure Applications".

This paper is a "must-read" if you are considering developing applications using Windows Azure. It is also helpful if you plan on developing applications in the cloud in general.

It contains the following sections:

• Overview of Windows Azure Security-Related Platform Services
• Designing More Secure Windows Azure Services
• Creating More Secure Windows Azure Applications
• Applying Microsoft Security Development Lifecycle (SDL) Practices to Windows Azure Applications

It also contains the following useful appendices:

• Windows Azure Deployment Security Threat Matrix
• Excerpt from the Windows Azure Partial Trust Policy Reference
• Using SDL-approved cryptography in Windows Azure Applications