Cottleston Pie

Fernando Felman’s thoughts on software development

  • Categories Navigation

  • Topics

  • Archives

  • Advertisements

Archive for the ‘Architecture’ Category

The journey has begun, or how to become a Solution Architect

Posted by Fernando Felman on July 14, 2010


I’m a developer with lots of experience in the .NET world. I have developed countless of systems for all kinds of scenarios using many different technologies available in the Microsoft solution stack. I want to become a Solution Architect. Can anyone please provide information how to do it?

I’ve seen this question countless of times and it’s usually the same story: you’re a brilliant technical person and now you’ve decided to take the plunge and become a solution architect. Problem is, how do you do it? Where do you start and what do you need to know?

Many times I see people focusing on the technical aspect of the role, suggesting to learn design patterns & principles or maybe a particular architecture type such as SOA. Sometimes, the focus is on the delivery methodology such as Agile or Kanban. I have decided that it’s time to present my view on this matter, which is more holistically and is in alignment to the definition provided by the International Association of Solution Architect (IASA).

It’s no secret that I’m working as a Solution Architect in Unique World, a fantastic workplace with extremely smart people. My view of this topic is really the summary of many years of experience and more recently, the outcome of having a great mentor in Unique World for the last 4 years.

Obviously, before we respond how to become a Solution Architect, we first have to define what exactly a solution architect is. There are heaps of different definitions on the net and probably each architect has his or her own opinion on the matter. I’m no exception, and for me a SA is a person who has all the competencies needed to successfully deliver a solution architecture.

Yes, I know this doesn’t help too much, so let’s break that into what solution architecture entails. A solution architecture of a software project is the blueprints of how, technically, a solution works. It should contain the following aspects:

  • Technology Composition – this is where you define what technologies you’re going to use, e.g. COTS like AD, SharePoint, BizTalk, Office tools, Internet Explorer but also development platform like WCF and WPF.
  • Information Model – this is where you define what information repositories you will have and how information will flow in the system
  • Logical Composition – this is where you define the logical components, including custom development, and how they interact in the system
  • Topology and Environments – this is where you define the service topology (e.g. servers and networks) of your system

Now, in order to successfully deliver a solution architecture, the SA should have a great deal of technical knowledge and be aware of many trends and options available for use. However, that’s not the end of the story. The SA should also possess soft skills and human dynamic skills to successfully communicate with both the business and the technical team, to fully identify concerns and influence-forces affecting the designs.

In essence, the SA must be an absolute brilliant technical person with great communication skills, and have good knowledge of Project Management practices & methodologies. Oh, and obviously, the SA must have perfect abstraction abilities, or else he’s doomed to drawn in the sea of details.

Now that we know what a solution architect is, it’s time to answer how to become one. Well, here the response is much simpler – the aspiring SA needs only to follow the development path created by the IASA , starting from here:

The International Association of Solution Architects (IASA) is the body of knowledge for a SA to align his or her career development with. The IASA identified the skills and competencies a SA should have, and also provide good learning materials and options to get there.

Another place to start looking at the role of an architect is these two articles. Although they are not in perfect alignment of how I see the role of the architect, they do provide a holistic understanding of what is expected from one.

So there you have it. My view of what a solution architect is and what should you do to become one. I would love to hear comments from the community around this topic.

It goes without saying that if you find this information helpful and wish to reuse and /or publish it, please provide the appropriate credit and link back to this page.

Fernando Felman
Solution Architect
Unique World

NB: the response I posted in this thread is the driver for this post.


Posted in Architecture | 12 Comments »

SharePoint integration in Visual Studio 10 (and my thoughts around their implied concepts)

Posted by Fernando Felman on November 27, 2008

Visual Studio General Manager, Jason Zander’s, revealed some very interesting announcements around the expected capabilities of Visual Studio 2010 and MOSS at TechEd EMEA 2008. I think this is very much in alignment to an implicit approach Microsoft is shifting to: enabling software development at an architecture and enterprise level, both in more general “tradition” areas but also specifically in SharePoint.

Microsoft launched the Patterns & Practices group for quite a while ago and this group is doing an excellent job enabling architects to develop repeatable-successful solutions using the Microsoft.NET Framework. The group provides reusable artifacts such as the application blocks and design patterns to leverage collective knowledge in order to enable predictable outcomes. In my opinion, this is essential when dealing with enterprise-level applications.

Relying on this managed knowledge means that architects can adhere to successful patterns when handling the overarching concerns of the solutions: we get answers on how to plan for a solution, what products to use, how to provide a build-cycle and what not. And, and this is most important, we are used to this richness of information. We depend on it.

However, when we leave the world of “traditional” technology, RIA, Web Site, Rich Client, Service, etc and we enter the world of Knowledge Management through SharePoint, we suddenly lose out trusty partner. We no longer use application blocks for developing web parts, we do not know how to make our solution testable, and we have to create our own methodology. In essence, we no longer leverage the collective knowledge. Now, you might argue that we have many reusable web parts and heaps of self-proclaimed “best practices” books but almost all of them deal with the technicality of SharePoint solutions, not the bigger picture of solution architecture.

Or at least that was the case in the past. Not so long ago the P&P group released the SharePoint Guidance presumably to bridge that gap, and that’s a good starting. Though I see there are many gaps and holes, especially when you try to bind it with the current Architecture Guide, I think this demonstrates a shift in the approach Microsoft is taking for SharePoint, an approach whose goal is to enable software development at an architecture and enterprise level, especially for SharePoint.

So, going back to the announcements Jason did – I think that these new capabilities in Visual Studio 10 is just another such effort from Microsoft to enable a full software development lifecycle and the VS tool aims to cover the development aspects of it e.g. these capabilities enable multi-members teams working on the same SharePoint solution.

Posted in Architecture, Moss | Leave a Comment »

Using CCF to integrate LOB applications

Posted by Fernando Felman on May 23, 2007

Here’s some news for the architects out there: check out CCF. CCF, which stands for Customer Care Framework, is an integration framework from Microsoft targeted for customer care environments (“call centers”). I was introduced to this framework on my last project in which I assisted in the architecture of an integration project for a customer care department.

The interesting thing about CCF is that the integration of LOB applications is done in the front-end layer, not in the middle tier. This is a great money saver for the business since it maintains the existing business logic and does not require re-development (as is the case in most SOA projects).

In a nutshell, CCF gives you the following:

  1. Non-disruptive integration layer: the integration of existing systems is done on the call agent’s desktop by hosting the applications. The hosted application is not modified (its source code shouldn’t be touched) so the business logic and the data validation of the application is honored. CCF can automate the UI of the hosted applications based on the customer’s context (the customer being handled by the call agent).
  2. Configurable business scenarios: CCF supports “workflows” to assist the call agents in using various integrated systems to perform a single business operation. For example, the scenario “create customer” might include updating the accounting systems and the product systems. Using CCF workflow the admin can deploy a “Create Customer” business scenario that redirects the call agent to the relevant systems (and if automation is implemented, CCF can further assist by automating the manipulation of fields in those relevant systems).
    Note: the term “workflow” is not the best ever, a guided wizard would be more accurate (and that’s why I’ll never be a salesman).
  3. Customer-context driven development: one of the key aspects in CCF is the Context which contains the fields associated with a customer. CCF can then use the context in order to automate hosted systems (so the CRM will automatically perform a customer search when the context is loaded to the CCF) and it can also forward the context to other agents (so if you’re redirecting between call agents, your session is always maintained).

It is important to notice that CCF is not a solution, but rather it is a framework. You won’t be able to “install and go”, you’ll have to learn the tools and concepts and develop your solution accordingly. Once learned, CCF can really add value to customer care related integration projects.

Posted in .Net v2, Architecture | Leave a Comment »