IT is just IT

Let’s talk shop

2011-09-27T17:58:00.000+02:00

My experience as an Open CITS Certification Board Member

The Open Group Certified IT Specialist (Open CITS) certification program — formerly ITSC — is an independent global certification program for qualifying the skills, knowledge and experience of IT specialists. Accepted and applicable worldwide, from a wide range of organizations in more than 50 countries worldwide. Capgemini’s internal Software Engineering Certification Program is an Accredited Certification Program and adheres to the Open CITS Certification Policy and Open CITS Accreditation Policy. Certified Software Engineers on levels 2 and up benefit from the accreditation, because it provides them the opportunity to attain Open CITS certification with a little extra effort. The Open CITS certificate represents an ideal mechanism for Capgemini’s Software Engineers to demonstrate knowledge, success and overall business capabilities outside Capgemini.

The Open CITS program requires applicants to demonstrate skills and experience against a set of conformance requirements through written applications and peer interviews. There are no training courses to attend, and no written exams to complete. However the Open CITS program requires candidates, who are not able to leverage an accredited certification program, to submit a comprehensive certification package detailing their skills and experience gained on working on IT projects to the CITS Certification Authority, followed by a rigorous peer review process. The Open CITS Certification Board is responsible for executing this process and membership is by invitation only. Capgemini software engineers certified on level 3 and 4 might be approached by the Global SE Community Leadership with the question if they would like to consider to join the CITS Certification Board. In June 2010 Richard Challis, who was already residing on the board, recommended me to the authority as a candidate member, after which the authority invited me to join. I was honored by the invitation and I accepted my membership to the board without hesitation.

The Open CITS certification process itself basically consists of three stages. After a certification package has been submitted a board member reviews the package in stage one. The Open CITS certification policy is very strict: all certification requirements have to be met, no exceptions. Every candidate I’ve reviewed myself was not able to pass this tollgate on the first try. Across the board the experience is the same, which is hardly a surprise given the very specific and strict requirements for the 30 page package. Fortunately for the candidate the certification process allows the candidate to update the package, in those cases the reviewer is confident the candidate should be able to pass the tollgate with some enhancements to the package. For me as a board member this is a great opportunity to provide feedback to the candidate to enable him to create a package which gives him the best possible point of departure for stage two of the process.

Stage two of the process is the Board Evaluation. Compared to Capgemini’s internal process this stage is very demanding for both candidate and board member. While during our internal process the certification board conducts a single interview with each candidate as a group, the CITS procedure is more demanding. Each candidate will be assessed by a board consisting of three members. Each member has a 1 hour individual interview with the candidate, who is asked to amplify his certification request and clarify any gaps the board member may have discovered during his review of the accepted certification package. The three one hour interviews are very demanding for the candidate, but I myself as a board member is not spared either. I may have to prepare and conduct up to 5 interviews during a session of the certification board, which may require me a couple of days to review up to 150 pages of certification packages and prepare my questions for each of the interviews.

The final stage three is the Board Approval step. During a board-confidential consensus meeting held on the same day as the interview the board members discuss each candidate individually. Leveraging the information in the certification package and the observations during the interview each member provides feedback whether or not the candidate should be accepted. Finally the three members take a vote. The candidate is accepted by majority vote. In case of decline the board unfortunately has to provide feedback to the candidate about the rational for the decision. In most case we will encourage the candidate to reapply for certification in due course once he gained the professional software engineering experience required for CITS certification.

Even though my CITS certification board membership is not without obligations, the work and effort required is very satisfying. Not only provide my duties for the certification board me with the opportunity to affirm my professional skills with regard to providing professional feedback and interviewing professional peers. I also get the opportunity extend my own professional knowledge with the insights I gain from the professional knowledge and experience expressed and illustrated by the candidates, when they talk about their own work as an IT professional for organizations from all over the world. It’s needless to say the membership enhances my professional network as well. And bottom line: How often does one usually get the chance to intensively talk shop with professional peers outside Capgemini about his or her insights and point of views for an hour? There are only a few things which compare to sharing once professional passion for IT amongst peers and at the same time uphold and improve the professionalism of the individuals which make up the global IT Community.

A Software Developer's Reading Plan

2010-02-20T12:55:00.002+01:00

This list describes the reading program a software developer needs to work through to achieve full professional standing. The plan described is a generic baseline plan for a software professional who wants to focus on development.

Introductory Level
To move beyond "introductory" level, a developer must read the following books:

Adams, James L. Conceptual Blockbusting: A Guide to Better Ideas, 4th ed. Cambridge, MA: Perseus Publishing, 2001.
Bentley, Jon. Programming Pearls, 2d ed. Reading, MA: Addison-Wesley, 2000.
Glass, Robert L. Facts and Fallacies of software Engineering. Boston, MA: Addison-Wesley, 2003.
McConnell, Steve. Software Project Survival Guide. Redmond, WA: Microsoft Press, 1998.
McConnell, Steve. Code Complete, 2d ed. Redmond, WA: Microsoft Press, 2004.

Practitioner Level
To achieve "intermediate" status, a programmer needs to read the following additional materials:

Berczuk, Stephen P. and Brad Appleton. Software Configuration Management Patterns: Effective Teamwork, Practical Integration. Bosten, MA: Addison-Wesley, 2003.
Fowler, Martin. UML Distilled: A Brief Guide to the Standard Object Modelling Language, 3d ed. Boston, MA: Addison-Wesley, 2003.
Glass, Robert L. Software Creativity. Reading, MA: Addison-Wesley, 1995.
Kaner, Cem, Jack Falk, Hung Q. Nguyen. Testing Computer Software, 2d ed. New York, NY: John Wiley & Sons, 1999.
Larman, Craig. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process, 2d ed. Englewood Cliffs, NJ: Prentice Hall, 2001.
McConnell, Steve. Rapid Development. Redmond, WA: Microsoft Press, 1996.
Wiegers, Karl. Software Requirements, 2d ed. Redmond, WA: Microsoft Press, 2003.
"Manager's Handbook for Software Development," NASA Goddard Space Flight Center.

Professional Level
A software developer must read the following materials to achieve full professional standing. Additional requirements must be tailored to each individual developer; this section describes the generic requirements.

Bass, Len, Paul Clements, and Rick Kazman. Software Architecture in Practice, 2d ed. Boston, MA: Addison-Wesley, 2003.
Fowler, Martin. Refactoring: Improving the Design of Existing Code. Reading, MA: Addison-Wesley, 1999.
Gamma, Erich, et al. Design Patterns. Reading, MA: Addison-Wesley, 1995.
Gilb, Tom. Principles of Software Engineering Management. Workingham, England: Addison-Wesley, 1988.
Maguire, Steve. Writing Solid Code. Redmond, WA: Microsoft Press, 1993.
Meyer, Bertrand. Object-Oriented Software Construction, 2d ed. New York, NY: Prentice Hall PTR, 1997.
"Software Measurement Guidebook," NASA Goddard Space Flight Center.

How do you define scope yet remain agile?

2010-02-18T14:58:00.001+01:00

Here is a common question I get regularly. In this case it was Howard, a co-worker from the UK: “Probably a dumb question but...how do you define scope yet remain agile? Is it woolly wording, do you define it using some kind of abstraction or do you define in terms of number of iterations? The key being that, in my experience, most people what some idea of what they're getting up front, yet in remaining agile we want to defer that sort of decision until later.” This is not at all a dumb question because it identifies the key difference between agile and traditional project delivery. Here is my response to the questions.

In my projects scope is a matter of defining this at the right abstraction level, or maybe more precise defining it without much detail. First thing you need is an concrete idea about the project’s scope boundaries. You can use the business case and vision for this purpose. They should provide the constrains with respect to for example business processes to support or available time and budget.

Next step is to make a first inventory of the functionality to be developed. You can use a business process model and/or use case model for this purpose. At this point in time you only define the outline for each process and/or use case with just enough detail to get a general idea about it’s function in the process and a preliminary idea of the complexity, i.e. the expected cost for the realization. This provides both a general idea of what will be build at what cost. This is the infamous backlog everybody is talking about.

And to make the project delivery agile, here is the key point: The project team has to be willing to change the content of the backlog as the project gets along, more detailed information about the problem at hand comes available and the client’s needs change. And this change actually should be exchange. If a new backlog item is identified this should be exchanged by a low priority backlog item we thought we would up front. You probably do want to keep the cost for the project constant or otherwise you need to find you a sponsor for new backlog items.

This is also the reason backlog grooming is so important. The team should keep the backlog up to date and the high priority backlog items should be more detailed than those with low priority. This constant reevaluation of the backlog in collaboration with the client is your guarantee you will actually deliver the solution the client actually needs and not the solution he thought he needed at the start.

So bottom line: you do need to set a scope for a project, but only with just enough detail to get an initial cost estimate and budget. And if you want to deliver the project agile, both you and the client must willing exchange low priority backlog items with newly discovered functionality which has a higher priority or value to the client, keeping project cost constant.

Going through the numbers: what kind of scope can your agile delivery platform handle anyway?

2010-01-09T19:00:00.000+01:00

Today a manager asked what kind off scope and effort the Accelerated Delivery Platform could handle on a project expressed in function points. I find this a very odd question and I have always been resilient to function point analyses as an estimation technique which tries to best guess the end state of a software solution based on and determine by the number of interfaces, screens, reports etcetera. Often this happens upfront at a point in time there is only a vague idea for a perceived solution for specific problem which still needs to be analyzed in detail. Very old school thinking if you would ask me, which is not helpful for providing agile ICT support for business development and transformation.

Asking for the ADP platform’s project delivery capabilities expressed in scope and effort is a weird measure for suitability for a software development platform. Given infinite time any scope and effort can be handled by any approach. But then again every project is always about time and scope, even when a Product Owner says it is not. His manager most certainly does want to get some added business value in the near future.

A focus on a potential optimal scope is also the wrong mindset for ADP, which stands for fast and disciplined agile software delivery in accordance with the collaborative business experience: we now start to develop the functionality the client/product owner needs most in two weeks’ time. The size or scope of this package of functionality is equal to the capacity the team can handle comfortably and maintain.

So what counts is the productivity or delivery speed of the software development team, since you can scale the size of a project team in principle to any size. And this delivery speed itself can be expressed in hours per function point. And if you are now wondering what kind of productivity can be established with ADP, I can’t share because of company confidentiality. What I can tell is the people are really astonished and in disbelieve when I am allowed to disclose and it is a loooong way below the industry average.

For this reason ADP is best done justice in a long running software delivery program, like for example in the actual case in which for a long period of time a client is provided with an ADP software delivery factory for the initial solution development and following application management. There are however a few constrains to keep the factory agile and responsive for the client: The initial development and deployment to production of a new solution has a standardized project delivery cycle of 100 days and every 2 week sprint delivers working software, fit to be made available to the business. And every new project the users of the new solution are amazed they actually can see and test the initial results after a few days and have a finished piece of functionality after two weeks.

If you are still interested in the optimal scope, we have to go through some numbers. There do exist constrains on the span of control for a project team and the available capacity at the client/product owner required for requirement & test workshops. In ADP projects we actually do elaborate with the ambassador users on requirements and they do need to test and signoff for a successful end result for a Smart Use Case at the end of the sprint.

For development work required on a Smart Use Case you need a dedicated cross-functional team consisting out of 3 engineers responsible for requirements, design, code, test & deployment. Besides we need an assumption for the overhead (-for project management, engagement management, configuration management, tool support, framework engineering, town hall meetings, community of practice meetings, etcetera-), especially required because remember we do want to run this project at scale. For now let’s put the overhead at a constant 0,5 FTE per team.

And mind me this overhead is not wasted time, because teams do need time and effort to align their team’s individual contribution with the rest of the project. And if you want to do this at large, like we intend to do here, this does require more effort compared to a single team approach with on average only 7 team members.

The complexity of a use case is also a relevant factor. For a matter of fact this determines the effort required by the team. Higher complexity requires more effort. Fortunately for us our team is using ADP’s Smart Use Cases. Smart Use Cases deliver smaller and equally granular use cases to software development. As a result the average complexity of this kind of use cases in a project is “Average”, which by definition in ADP is equal to 4 Smart Use Case Points.

If your project’s average is way above this mark, my experience is you have to look into your use case model and determine the cause. There might be a perfectly good explanation due to project specific characteristics. Otherwise you might have overestimated some use cases or created a lot of complex use cases, which you might want to try and split into sub functional use cases. these contribute a specific part of originally considered functional scope, often identified when you look for intermediate results.

Are you still with me? We are half way through setting some of the numbers in place. You might want to consider to reflect a bit on the preceding, before you proceed and consider the effort required by the product owners team. And this is actually key to make the agile collaborative business experience successful for an ADP project engagement with a client.

So what do we need and expect from the client/product owner? We do need his input, business knowledge, support and commitment. This implies he needs to make staff members, the ambassador users, available for collaboration with the software development team and this comes at a cost. The staff members will not be available for their business during the time they support the engineers. This has impact on the capacity available to execute the regular business tasks.

On average the development team requires about 8 hours of contact a week with the ambassador users a week to elaborate on the details of the Smart Use Cases and discuss and test the results provided by the engineers, which are in scope of the current sprint. The elaboration is done during intensive facilitated workshops.

The question which arises is: how many ambassador users are required to attend the workshop? And this can be a though question. I have had my fair share of workshops which more resembled a bedlam than a professional meeting, due to more than a dozen stakeholders in a workshop, who all wanted to get their point across and get recognition for their personal needs. I think you can imaging and see the three men engineering team struggling to get them all aligned for a suitable solution for the problem at hand? I can tell you those were not very productive meetings at all.

Having gone through the ropes my personal experience is ideally you have three ambassador users in a workshop, each providing and focusing on a specific aspect of and viewpoint on the Smart Uses Cases, which are the subject for the workshop. As a result you have a total of 6 participants in the workshop. This provides the ideal setting for focused elaboration, given all participants sufficient room to actively participate in the session.

There is however a condition which must be met to make the workshops a success. All participants, the ambassador users as well the the engineers, must have a mandate from both the product owner as well as the project manager to make the required functional design decisions about the Smart Use Cases which are in scope of the workshop and execute them without consultation.

But you have to be on your toes with regard to the mandate. During a workshop one might discover an issue, which is beyond the functional scope of the meeting and has wider impact. This can be an impact on the technical solution as a whole. But it might as well be an issue at the business side. And again, please remember we are running this project at scale and as a result not all concerned parties are in the workshop. This requires all the project participants to be on their guard and escalate these impediments through the proper channels in the project’s organization.

So what is the take on the specific aspects and viewpoints for the ambassador users you wonder? Ideally each ambassador user has a specific stake in the problem. First in line is the representative for end users. The end users will work on daily basis for years to come with the solution, which is being developed. As a result their opinion is key with regard to the acceptance of the solution and their voice must be heard and most certainly be taken into consideration. The implication is that ideally the end user representative is someone who actually will work with the Smart Use Cases at hand in the future. My advice is to assign this type of Ambassador user to the project for the time the functionality he is actually going to use is within the scope of current sprint. On a large project this might result in a very dynamic group of participants.

So with the end user representative in place, my observation is we have actually placed a kid in a candy store with a mandate to pick all the sweets he can handle, basically having a blank cheque with the capability to burn more project budget than required or expected. We need a counterbalance to prevent this from happening.

The engineers are not the suitable persons to act as the counterweight. They basically do not have a great interest in how the available budget for the project is spend as long as the end user representative is happy to signoff the realized solution for the Smart Use Cases.

The Product Owner is accountable for the project’s budget, so he should make sure his voice is represented in the workshop. The Product Owner has to assure himself the requested solution is aligned with the business vision for the project and fits in the available budget. For this reason and because we are running a large operation and as a result the Product Owner can’t attend all workshops, he needs to delegate a representative to the workshop.

The third type of ambassador user I need aboard a workshop is the domain expert, commonly holding the title Business Analyst. He is the subject matter expert with the bigger picture about the business model the solution needs to support and is aware of the interdependencies between individual user tasks that need to be support by the solution. He also possesses the detailed business knowledge the solution has to support. He is the business rule guy who needs to make sure the solution underpins and supports the Client’s business governance model.

So on average we need 3 ambassador users for 8 hours a week to collaborate with the engineers in workshops. The ambassadors also require some time to prepare for workshops and look into matters. Because we are running at scale we also need to anticipate some overhead for elaboration between the different user teams who are each collaborating with an engineering team. Let’s say this requires an extra day in the week on average.

We end up with the following equation: for each engineering team on the project, requiring 3.5 FTE, we require 1.6 FTE from client. If for example the client is able to spare 16 FTE on the project, an engineering team of 35 FTE can be assigned, having a total of 51 FTE elaborating on the solution.

In my opinion with 51 FTE we have also reached the other constrain I mentioned earlier: span of control. On an agile project you do want to have those involved knowing what is going on. In my experience a group of people knows what is going on if they all can fit in one bus. It a group needs to travel in more than one bus, it’s hard to get a clear picture on what is going on in the other bus. As a result my conclusion is you should not have more than 35 engineers on a project if you want to keep every body involved, informed and committed.

Having identified the 35 engineers constraint, I am able to answer the manager’s original question and I am sure he will be really astonished and in disbelieve. But then again that is what happens all the time ADP’s productivity is revealed.

When did you have your last check up?

2009-12-17T13:55:00.003+01:00

I was recently certified as Level 3 Software Engineer by the GCB. In this article I elaborate on how I used the SE Certification Program for my personal career development.

Having a regular check up on the things that surround you has become a fact of live in our society which depends highly on technology. Sometimes these inspections are required by law,like the periodic motor vehicle test for my car. You have the condition of your central heating checked in the fall, to make sure it doesn’t break down on the first day of winter. Or you just want to take good care of yourself and have your teeth checked by your dentist every half year to spot tooth decay early. So basically you have a regular check on to make sure everything functions to expectation and is up to the mark.

As a certified and qualified professional software engineer I also need to make sure my skills are up to the mark. The professional standards which came with my engineering degree actually demand me to keep up with current technology. This should not come as much of a surprise in an industry which seems to reinvent itself every 5 to 10 years. Ever since I decided to have a career in ICT Industry I have been aware of this and certification has always been my tool to retain my market value as a professional engineer.

When you start your career as an engineer you tend to focus on on a publically recognized certification program in the market from our partners like for example Microsoft’s MCTS. This will indentify you as an able professional in a particular technical field and add to your value on the job market as well as for Capgemini. But what you are actually doing with this kind of certification is making our partner’s solutions a valuable success for our clients. That is just fine and valuable for Capgemini. But what it does not provide you is explicit recognition of your personal added value to Capgemini, which is the value you personally provide on top of the external certification and which distinguishes you from other certified engineers in the job market.

And this is exactly the reason why I invest time and effort to pursue Capgemini’s own SE Certification Program. This has just now taken me to Level 3, the entry level for Capgemini’s SE Club d’Experts, the best skilled software engineers within Capgemini. It has also significantly contributed to my recent appointment as Managing Consultant and thus provided a boost in my career.

The SE Certification Program sets concrete targets to achieve, not only with regards to personal technical knowledge but also with regard to your personal contribution to sales, project delivery, knowledge sharing and last but not least the Capgemini way. I used these criteria as input for my personal development plan and define smart targets for my annual evaluation. This in turn provided me with assignments and training to set the right context for my personal development. I created a professional environment for myself to grow and in the mean time made my personal contribution to Capgemini explicit.

As a result my recent SE Level 3 certification provides the proof I am ready to contribute to the Capgemini’s most complex engagements according to corporate guidelines, the law. The certificate also vouches for the condition and health of my personal and professional skills in a wider perspective than just technical excellence. So I now know for sure my skills are up to the mark and I am ready for my next professional challenge and the next step in my career.

So if you like to be challenged and drive your professional future within Capgemini, my advice to you is to use SE certification to steer your personal professional development and boost your career. Contact your regional Software Engineering Board representative if you are ready for your professional check up.

UI Pattern Library

2009-03-06T22:37:00.003+01:00

Infragistics, the guys that are powering the UI layer, are showing of their Silverlight capabilities with their glossy restyled UI Pattern Library. This kind of demo makes me envious. It's about time I start delivering this kind of solutions to my clients myself. I guess it's back to the drawing board and figure out how I can mash this together.

A great SOA pattern catalog

2009-01-29T15:34:00.005+01:00

Today I was struggeling with howto route messages through a complex service infrastructure. As usual I consulted Dr. G. Oogle. The doctor was so kind to refer me to http://www.soapatterns.org. The site is a gold nugget for SOA patterns. And I think I will take look at the companion book SOA Design Patterns by Thomas Erl.

The Back of the Napkin: Solving Design Problems (and Selling Your Solutions) with Pictures

2008-03-10T22:14:00.003+01:00

Speaker: Dan Roam
Description: Let's face it: describing user experience is hard... unless we use pictures. This session demonstrates step-by-step how anyone, regardless of artistic talent or training, can use simple pictures to describe complex design and technical concepts, solve fuzzy problems, and sell others on breakthrough ideas:

The Back of the Napkin: Solving Design Problems (and Selling Your Solutions) with Pictures

MS Sliverlight 2.0

2008-03-10T01:41:00.003+01:00

Building Rich Internet Applications Using Microsoft Silverlight 2, Part 1

Exploring the Domain-Specific Language Tools

2007-01-15T18:21:00.002+01:00

I'm currently familiarize myself with the Microsoft's concept of Domain-Specific Languages. And I must say I'm having a hard time collecting usefull information on the concept. It seems that beside the content in the MSDN Library and a rare presentation on Channel 9 there is not much information out there on the web. Well let's see where the subject takes me. Anyway, this subject should keep be busy this week, before I plunge down in the world of Cordys for 4 weeks.

My definition on Service Oriented Architecture

2006-10-12T01:58:00.001+02:00

SOA = given a generic service capability of a service provider the ability to dynamically apply business rules on the generic business processes and the generic information objects to create specific processes and specific objects which are able to respond to the specific service requests from service consumers in a certain context.

The Seven Greatest SOA Mistakes

2006-10-08T14:53:00.001+02:00

SOA is clearly The Next Big Thing, but many companies run the risk of jumping into the approach without looking at where they are leaping. Here is a list of some of the most common pitfalls that could tie a SOA installation into knots.

Your webservicecalls on steroids?

2006-10-08T14:45:00.001+02:00

Take a look at Expect100Continue!

When this property is set to true, client requests that use the POST method expect to receive a 100-Continue response from the server to indicate that the client should send the data to be posted. This mechanism allows clients to avoid sending large amounts of data over the network when the server, based on the request headers, intends to reject the request. For example, assume the System.Net.Sockets.ServicePointManager.Expect100Continue property is false. When the request is sent to the server, it includes the data. If after reading the request headers, the server requires authentication and must send a 401 response, the client must resend the data with proper authentication headers. If this property is true, the request headers are sent to the server. If the server has not rejected the request, it sends a 100-Continue response signaling that the data can be transmitted. If, like in the previous example, the server requires authentication, it sends the 401 response and the client has not unnecessarily transmitted the data.

Changing the value of this property does not affect existing service points. Only new service points created after the change are affected.
The Expect 100-Continue behavior is fully described in IETF RFC 2616 Section 10.1.1

See: ServicePointManager.Expect100Continue Property

With regard to the above the following backgrouder might be usefull to you:

Understanding System.Net Connection Management and ServicepointManager

MSDN Gold nugget: Designing .NET Class Libraries

2006-10-08T13:39:00.001+02:00

The Designing .NET Class Libraries series presents design guidelines for developing classes and components that extend the .NET Framework. The goal of the Designing .NET Class Libraries series is to encourage consistency and predictability in public APIs while enabling Web and cross-language integration. The guidelines presented in Designing .NET Class Libraries are intended to help class library designers understand the trade-offs between different solutions. There might be situations where good library design requires that you violate these design guidelines. Such cases should be rare, however it is important that you provide a solid justification for your decision.

You can find the transcripts of the chats related to these presentations in the .NET Framework Chat Transcript Archive.

MSDN Gold nugget: Designing .NET Class Libraries

MSDN Gold nugget: Design Guidelines for Class Library Developers

2006-10-08T13:06:00.001+02:00

The .NET Framework's managed environment allows developers to improve their programming model to support a wide range of functionality. The goal of the .NET Framework design guidelines is to encourage consistency and predictability in public APIs while enabling Web and cross-language integration. It is strongly recommended that you follow these design guidelines when developing classes and components that extend the .NET Framework. Inconsistent design adversely affects developer productivity. Development tools and add-ins can turn some of these guidelines into de facto prescriptive rules, and reduce the value of nonconforming components. Nonconforming components will function, but not to their full potential.

These guidelines are intended to help class library designers understand the trade-offs between different solutions. There might be situations where good library design requires that you violate these design guidelines. Such cases should be rare, and it is important that you provide a solid justification for your decision. The section provides naming and usage guidelines for types in the .NET Framework as well as guidelines for implementing common design patterns.

MSDN Gold nugget: Design Guidelines for Class Library Developers

Elements of Service-Oriented Analysis and Design

2006-10-08T11:41:00.001+02:00

An interdisciplinary modeling approach for SOA projects

The basic concepts of Service-Oriented Architectures (SOAs) and Web services are becoming part of our everyday language and recognized as a suitable architectural style for crafting modern enterprise applications. In this context, the underlying issues of: what makes good services are becoming increasingly critical for ensuring the successful implementation of SOAs.
Existing modeling disciplines such as Object-Oriented Analysis and Design (OOAD), Enterprise Architecture (EA) frameworks, and Business Process Modeling (BPM) provide us with high-quality practices that can go a long way in assisting with the identification and definition of appropriate abstractions within an architecture. However, experience shows that these practices fall short when being applied independent of each other.

In this article, suitable elements are investigate from OOAD, EA, and BPM. The article also motivates the need for a hybrid approach that combines elements of all of the disciplines, with a number of distinct, new elements. The resulting, interdisciplinary OOAD method facilitating successful SOA deployments, which is refered to as Service-Oriented Analysis and Design (SOAD), has yet to be formally defined. With this approach you can take the first steps into the SOAD space.

Patterns: Service-Oriented Architecture and Web Services

2006-10-08T11:37:00.001+02:00

The Patterns for e-business are a group of proven, reusable assets that can be used to increase the speed of developing and deploying Web applications. This IBM® Redbook focuses how the Self-Service and Extended Enterprise business patterns, and the Application Integration pattern, can be used to start implementing solutions using the service-oriented architecture approach.
It guides you through the process of selecting and applying Business, Application and Runtime patterns. Next, the platform-specific Product mappings are identified based upon the selected Runtime pattern.
The book presents guidelines for applying the Patterns and service-oriented architecture approach to a sample business scenario and for selecting Web services technologies.
It provides detailed design, development, and runtime guidelines for several scenarios, including synchronous and asynchronous service buses, UDDI service directory, and the Web Services Gateway.
The book concludes with an examination of how a service-oriented architecture can provide a step in the direction of IBM's e-business on-demand vision.

A repository of architecture resources

2006-10-01T12:06:00.003+02:00

Back in April 2005, IASA, the International Association of Software Architects, formed a working group focused on IT architectural "Foundations & Taxonomy" with the specific goal of charting the "largely uncharted" profession of IT architecture.
One objective of the F&T Workgroup is to locate, qualify, sort, coordinate, and explain resources relevant to IT architects. You can access this Architecture 'Resources' Repository by clicking the following link:
http://www.itscout.org/itguide/login.cfm?rdtk=63C7707AB50A91D2607E9E2641CC48D8

Service-Oriented Modeling and Architecture: How to Identify, Specify and Realize Services for Your SOA

2006-10-01T12:06:00.002+02:00

A huge demand exists for the development and implementation of SOAs. Learn how SOA can help bridge the gap between business and IT through a set of business-aligned IT services using a set of design principles, patterns, and techniques.
This article discusses the highlights of service-oriented modeling and architecture; the key activities that you need for the analysis and design required to build a Service-Oriented Architecture (SOA). The author stresses the importance of addressing the techniques required for the identification, specification and realization of services, their flows and composition, as well as the enterprise-scale components needed to realize and ensure the quality of services required of SOA.

REF: Patterns and Best Practices for Enterprise Integration

2006-10-01T12:05:00.001+02:00

Enterprise Integration Patters

This site is dedicated to making the design and implementation of integration solutions easier. The solutions and approaches described here are valid for most integration tools and standards such as IBM WebSphere MQ, TIBCO, Vitria, SeeBeyond, WebMethods, BizTalk, JMS, MSMQ, Web Services etc.

REF: Martin Fowler's Catalog of Patterns of Enterprise Application Architecture

2006-10-01T12:04:00.003+02:00

Martin Fowler's Catalog of Patterns of Enterprise Application Architecture

A short summary of the patterns in Patterns of Enterprise Application Architecture (P of EAA).

REF: Development of Further Patterns of Enterprise Application Architecture

2006-10-01T12:04:00.002+02:00

Development of Further Patterns of Enterprise Application Architecture

REF: Institute For Enterprise Architecture Development

2006-10-01T12:02:00.001+02:00

Institute For Enterprise Architecture Development

IAF@MSDN: Enterprise Architecture Design and the Integrated Architecture Framework

2006-10-01T11:59:00.001+02:00

Enterprise Architecture Design and the Integrated Architecture Framework
Andrew Macaulay
CGEY
January 2004

Summary: Describes Capgemini's Integrated Architecture Framework, and describes a model for enterprise architecture and its importance in helping software architects understand the business as a whole. (8 printed pages)