SOA Design Patterns

According to an article about SOA design patterns, they are patterns that relate to other patterns. What that means is that "in order to apply one pattern, you may be required to apply (or have already applied) another."(PCWORLD)

What these SOA patterns do, aside from relate to one another is to provide a framework for real world applications. For example:" a pattern called Logic Centralization essentially establishes a rule whereby, for any given reusable body of solution logic, only one official service can exist. This reduces the risk of redundancy and maximizes reuse potential among services within a given domain." Here this pattern is applied: "imagine a service that encapsulates several databases and a legacy system. Even if we centralize the logic represented by the service, we are still not doing anything to prevent all of these underlying resources from being accessed directly via traditional-style integration channels. This is where Contract Centralization enters the picture.
The Contract Centralization design pattern limits external access to a service to its published technical contract (or interface or API), which means that the underlying resources cannot be touched by outside programs or applications (which we can refer to as service consumers), because the sole point of entry is the service contract.


As you can see this is quite involved but below is the link to the article for further reading.


http://www.pcworld.com/businesscenter/article/150569/working_with_soa_pattern_relationships.html

System Modeling

A water supply authority in Florida needed a good way to model potential sources of water. Turning to developers. the water supply asked for a way to model for the future. "The modeling tool would compare candidate systems based on ability to meet projected future demands for water. This ability is a function of both the actual raw water supplies available and configuration of the system components—the reservoirs, wells and water treatment facilities that produce finished water."

Using Microsoft Access, Visual basic, and a core modeling system called STELLA, developers were able to provide a fluid way to enter data and generate a model.

 One of the biggest challenges to this project was probably the development time frame of six months.

Beckers, C., Moore, E., Coates, M., & Hochuli, S. (2007). Modeling System Helps Authority Plan for Water Supply Needs. WaterWorld, 23(11), 16. Retrieved from EBSCOhost.

http://0-content.ebscohost.com.library.acaweb.org/pdf19_22/pdf/2007/WWR/01Nov07/27584355.pdf?T=P&P=AN&K=27584355&S=R&D=f5h&EbscoContent=dGJyMNLe80Sep7M40dvuOLCmr0mep65SsK64SbOWxWXS&ContentCustomer=dGJyMPGsr0y1q7NPuePfgeyx44Dn6QAAuthority

Issues with requirements

The biggest issue when obtaining software requirements lies in communication. According to the article I read Businesses often like to respond with lengthy, wordy descriptions about what they want to accomplish. Software developers on the other hand like to make diagrams and mock-ups (visual prototypes) of what the finished product should be like.

The problem lies in making sure that the requirements that are given in the first place are correct. According to the article rather than jumping straight into prototyping what is initially presented, developers should go back over the wordy documents presented to them by the client and analyze and verify it in the same manner. After this verification developers can move onto graphic representations of what they think the client is going to want. In this manner "Garbage in Garbage out" can be avoided.

Marasco, Joe. Dr. Dobb's Journal32. 9 (Sep 2007): 10.

Transitioning to Agile

An article in PC World Magazine (based on an excerpt from a book) details the best way a company can transition to an Agile methodology. This article is great because instead of focusing on any one project it describes how an organization can change their methodology, say from a waterfall, to an agile one. The key is change within, not from without.

When changing to an agile method in a company, Gregory Smith writes that the key is to have a core group that are not part of management but instead the actual developers. These core group members should also come from all "functional" areas of the company. "What better way to create awareness than to have Agile Core Team members come from each functional area. Imagine a member being from quality and going back to the quality team and telling them what is going on with the new methodology, or a developer doing the same with the development team." (Smith) The author, who is a CIO, strongly believes that by growing the agile methodology from within, instead of having outside consultants come in makes adaptation much more effective. This makes sense as you are much more likely to trust in a change from someone you "know" rather than a "know it all stranger". 

www.pcworld.com
The Core Dev Team's Role in an Agile Project
http://www.pcworld.com/businesscenter/article/153213-2/the_core_dev_teams_role_in_an_agile_project.html