Organisational Awareness Practice

The final area of practice is organisation awareness which can present certain challenges, some would call this area political aspects of the role, unfortunately the connotations this brings to up are completely misplaced. Politics is a reality of life and occurs the moment two people walk into the same room and of particular importance to the architect because it is politics the limits what can be achieved not the technology.

This area of practice is particularly hard to classify into the three group, because of much of this area is down to the integrity and value of the person.

A. As a minimum:

1. Understand that one need to get buy-in.
2. Understand to get a result that formal and informal processes are equally important.
3. Understand the stakeholders and their driving factors.
4. Accept that politics is required and that it is way of building consensus and aligning organisational forces.
5. Have a self starter initiative.
6. Is a good communicator at all levels.
7. Capable of building good genuine relationship.
8. Be an excellent provider of information.
   

B. In addition to (A) above the person with satisfactory skills would:

1. Capable of balancing organisational needs and engineering excellence.
2. Knows who within the organisation needs to buy-in projects and how & when to get their buy-in.
3. Understands the driving concerns of various team and departments within the organisation.
4. Able to 'sell' the architect to the various parties and can effectively manage their resistance.
5. Knows how to influence without resorting to authority or dominance.
6. Capable of coaching and assisting others.
7. Insight into the human condition.
   

C. In addition to (A) & (B) above, the person can be considered a technology leader or innovator:

1. Can influence the leaders within the business.
2. Understand the organisations political process.
3. Understands the power structure in the organisation.
4. Can identify key players within the organisation.
5. Respect and accepts the changing power structures within the organisation.
   

Strategic Practice

Like the technical competencies the strategic area is divided into three classifications, the first being the bear minimum that is expected, the second being representative of someone with satisfactory skills and the third being the required to be a leader field.

Bearing in mind that strategic competency is just one of the three areas that Architect needs to have master, yet it is very valuable and the area that brings most people undone.

A. As a minimum:

1. Understand the stereo typical application of the business's product or service.
2. Understands the business's market place.
3. Understand the strategy that has adopted to take the product or service to the market.
4. Layout tactical options which are in keeping with the architectural strategy.
   

B. In addition to (A) above the person with satisfactory skills would:

1. Understand the rationale behind the strategy that has been adopted.
2. Capable of investigating new technologies that could be leveraged to deliver a competitive advantage.
3. Capable of balancing immediate tactical requirements with long-term objectives.
4. Capable to road mapping the technology associated with the product or service.
5. Capable of setting the technical direction for a product or service.
   

C. In addition to (A) & (B) above, the person can be considered a technology leader or innovator:

1. Capable of setting the technical direction over the whole organisation.
2. Capable of bring together devise groups internally and externally to deliver strategic requirement.
3. Discover value creation opportunities.
4. Translate the business strategy into a technical strategy.
5. Explain the strategy to the developers and technical members in a relevant and meaningful manner.
6. Advise high-level strategy setters about technology and technical capabilities.
7. Be able to contribute at the strategic level of the business.
   

Some would say the above skills might more be in the realms of a CTO or CIO, the difference is that an Architect can only achieve his results via influence and therefore does not have any direct power as such.

Technical Practice

We have already talked at a high level what a Software Architect is and we have covered the three keys areas of practice. Here we will attempt to drill down on the technical aspects to provide an inventory of the necessary skills and experience the Architect needs to carry with him.

When we talk about technical skills, we are talking about Technology Competencies. I shall describe these in terms of three classifications, the first being the bear minimum that is expected, the second being representative of someone with satisfactory skills and the third being the required to be a leader or innovator in the field.

A. As a minimum:

1. Has been a specialist in a given technology and has worked with that technology on a day to day basis.
2. Currently can be considered a generalist with a very broad understanding of technologies from a vendor neutral viewpoint.
3. Is respected by developers on a technical basis.
4. Has current skills that allows them experiment with technologies and prototype ideas.
5. Can contribute to the development of a system.
6. Has an detail understanding of the application domain.
7. Has had ownership of at least a part of an application design.
8. Can deal with technical problems that are not clear or clouded by a number of factors.
9. Understands the concept of abstraction and is comfortable with creating abstractions to solve problems.
   

B. In addition to (A) above the person with satisfactory skills would:

1. Has a broad and deep knowledge of a number of technologies.
2. Is able to assess the maturity of a technology against a business's requirements.
3. Is abreast of the latest technology developments and research.
4. Has had experience managing a commercial application development.
   
5. Ability to work closely with developers to understand key elements of critical technologies.
6. Does not work at a code level day to day.
7. Has designed a commercial mission critical application.
8. Can handle high amounts of ambiguity and movable goal post.
9. Can proceed at an abstract level but has the ability to drill down to detailed technical level as required.
   

C. In addition to (A) & (B) above, the person can be considered a technology leader or innovator:

1. Can easily integrate key principles with new technologies.
2. Can invent new technologies or apply existing technologies in new innovative ways.
3. Can see market opportunities associated with new technologies.
4. Has had extensive developer experience over a industries and situations.
5. Has implemented and integrated opposing architectures in a complex organisational setting.
   
6. Has worked if not in all then many of the roles within a development team and understand the challenges that face people in those roles.
7. Understands the market offering of the organisations it's business model and its tactical and strategic advantages.
8. Is able to resolve ambiguity and uncertain situations.
9. Outstanding at working an abstract level across the organisation in a manner that can be directly linked back to technical details.

So as you can see the required skills go beyond coding ability and in may way coding is a cake walk compared to the other issues.

Passing Note

It has been a couple of weeks since my last post and every day I have been telling myself I need to post. Well today, well this morning, well in the next 15mins I have feel I thought I would do a quick note to let everyone know what has been happening.
I have need rushed off my feet of late with projects so there will probably be some interesting post in the next few on web services and as I am doing some WCF stuff it will be web services the Microsoft way.
The troubling thing is that I am still seeing bad OO code, one of the projects I have been working on is a maintenance and extension job to an existing web application. Nothing fancy just Oracle, Beans and JSP in a MVC pattern ‘Struts’.
Yet again, the team that cut the original code throw out all the benefits of, of the hundred or so classes, only a handful have been extended, everywhere else good old copy and paste, almost brings me to tears. The result is that they are creating more work, which does not necessary equal productivity, hence not adding the GDP.
Oh well I know I could write two books about the subject but for now I have to move on, and kill a few bugs.

Web 2.0 + SOA = Web Services

It is easy to be caught up in the hype and the latest terms, certainly, when your cabbie ask you about Web2.0 you know that marketing engine has been working in overdrive. Well that is actually, what happened to me today.

Whilst catching a cab today, my friendly cabbie asked me what I did, I replied with the standard line 'I work with computers' , Before I knew it he was telling about his son the wiz and asked me about Web2.0 and how I thought I would change the 'net'.

Therefore, this posting is for you George...

Web2.0, SOA, Web Services are all so interconnected I cannot do the subject justice by covering just one area. The whole push behind web2.0 is to allow people to work to collaborate and discovery new synergies. Web2.0 are software applications which are more like work environments that are inclusive and aims to bring the best out of your colleagues. As to what functionality these include, this is only limited by our own creative thoughts but these application will seek to leverage collective wisdom of people who where normally separated by distances, time zones and social economic barriers.

Social Bookmarking at del.icio.us is a great example of web2.0, its value and utility increases as more people participate; clearly, wiki is another great example that follows this rule.

However, here is the interesting thing the 'Technologies' behind the above two example are not new the same applies to many things we associate with Web2.0. I can a few voices off in the distance they are saying "What about AJAX"? Yes, the term is new, yet the enabling technology XMLHttpRequest has been around since 1999 if I recall correctly.

Yes, standards have been refined and new tools have made it easier to implement functionality, but as for enabling technology, most of it has been around for at least five years. Therefore, it would be fair to say that Web2.0 is the application of web/internet technologies in new and creative ways. This in itself speak mountain for the human creative spirit, I like to think of it as Web1.0 is characterized by humans duplicating what they had in the physical world online and Web2.0 is characterized by human discovering new way of doing things without the shackles of physical work practices, traditions and limitations.

So what does this all have to do with SOA (Service Orientated Architecture)? Well like Web2.0, SOA is about doing things differently, without the restrains of old world thinking and old world habits. Now there are some, which believe that this new world thinking is a fad and the cite pass things such as Modular Programming of the 70's, Event-Oriented Deign of the 80's and Component Approaches of the 90's. For anyone who has lived each of the above they would not say it is fad rather evolution.

Clearly, I was not coding in 70, but I have maintained allot of code from that, era and anyone can see that Modular Programming has influenced the single responsibility concept that all us OO Architects bang on about today. The same applies to the Event-Orientated approach that was so hot in the 80's, which has greatly influenced messaging today. The same applies for Components in 90's which today is still realized in many of our current designs. All of these approaches have stood upon the shoulders of their parents and the same applies to SOA.

OK we know that SOA is way of design a style if you will and we know where is has come from, it heritage but what is it?

From my perspective as an Architect, Service Orientated Architecture is way of putting together a system or application that uses existing systems/services and newly built components systems/services in such a manner that quickly, and cost effectively meets an organisations objectives whilst cutting across ownership boundaries.

Let us get practical; in this example, the brief is to deliver an email and SMS marketing application. After studying and decomposing the requirements, we can draw some big boxes on a white board. The first box is something to send and receive emails and another box to do the same for SMS's, another to compose the messages and one to maintain a list of folks who would get marketing message then on top of all that we need another box to report outcomes from these activities.

Reality check... if the above was the requirements we could probably find a few services that provided it all today and we just hook-up to their API to move data back and forth and write some report stuff.

However, let us for this example assume such a service does not exist and will not likely to exist in the future.

In the old days, we would have just built a 'sendmail' server and hooked up the serial post of the same server to a mobile phone to drive the SMS stuff. (Clearly not thinking about scalability issues here) Then we would have written heap and heaps of code and then probably a GUI and an import and export function so we could move data to and from the customer database.

Being that this is the enlighten age we would use a third party SMS provider or if one did not exist we would seek out a partner to own and operate a SMS service after we built it. Being the enlighten age we will build the SMS box/gateway in a fashion that was independent of the rest of the application, so it could be used by other application and other parties in the future.

In doing this, we would be concerned about coupling at the service level as well as the implementation level, we would ensure that way of communicating with this SMS box/gateway and getting to do stuff like sending SMS's and dump back replies where clearly define and that the inter-workings where clearly abstracted away.

Our objective here is to build a standalone SMS gateway that is capable of evolving to become the best SMS gateway around (will it be evolved is another matter which is commercial in nature).

We follow the same approach for our boxes, firstly looking for existing services, which are built to standards and using these if possible, then we consider building it with others and lastly build it in house (Clearly using another order if your core business was the provision of services).

In the ideal world, there would be services out there on the net that one could 'discover' and integrate together.

The above is the SOA style or way of building an application in addition to my perspective and there are generally accepted principal of SOA and reference implementations I strong recommend that every architect study and implement on their own.

The design principals are nothing new and you are probably using day to day as an architect, they are:

Abstraction

Autonomy

Compos-ability

Coupling

Discoverability

Encapsulation

Optimization

Reuse

Service/Interface Contracts

The only one in the above list I probably need to elaborate on is Discoverability, and certainly, this is an advance design feature. It should be noted that within the standards from OASIS, which I have strongly suggest, that everyone read, discoverability is necessary feature. In the commercial setting, unless you are building for a commercial provider it will probably not make the final cut on the specifications.

Discoverability is similar to reflection, it allows for the finding and querying of a service to get it measurements so to say. In a SOA sense where one is, building web services there is a couple discovery protocols you need to understand, being, UDDI and WS-Discovery. They both are different in that UDDI is more like a phone book (directory or service broker) and WS-Discovery is multicast 'who is out there' type protocol.

Also not to confuse but there is one more protocol to get you head around and that is WSDL, which is really simple it is basic a XML format that describes the web service , stuff like end points on the Net, address and ports and list of available command and any special data types.

You may have noticed the introduction of the term of web services in the last few paragraphs, well our SOA approach has lead us to build these boxes, which are, known as web services. Therefore, we can say that one of the artefacts of SOA is web services.

Within this realm or at this level also is a set of standards and specifics that can be used to find our out way out of the dark. These are from W3C and are again easy to get your head around, these standards position web services as client/server that exchanges XML messages that follow SOAP. There are alternative ways of doing this, but this is probably the simplest way, and there are plenty or reference implementations.

Therefore, as we can see web2.0 or peoples' creativity is driving the demand for new applications and the new way of building them is SOA when combined results in web services, that simple.

Leveraging Google

With the buzz about Web2.0, Mash up and SOA, I thought this would be an opportune time for a quick post on how an enterprise can leverage Google so that can go where no man has been before.

When we think Google we think search and rightly so they have had a major impact on that landscape, but search is not the only thing we should think. As of this moment there is probably some half dozen other major Google online applications which is not within the primary search space.

These applications which I am not including with the primary search space are Google Documents, Calendars, Base Data, AJAX, Checkout, Email and Blogger. If you include the rest like searching, mapping, ad words/sense, etc the list just sky rockets. What is more important is that Google have developed stable and well documented API's for these services.

Google clearly want folks to build applications that use their API, because these become additional channels, channels which are very sticky simple because once an organisation invest in learning and implementing an API they happen hang around for very long time. That said and understanding that one could spend a whole posting on the commercial issues, let move along to what we can do with this stuff.

Via the Google API's all of the Google Services have become 'Web Services' therefore a custom smart client or web application can be written to replace the existing heads. This in itself is not very interesting, given that the Google interface is so functional. The next step is integrating single services, like the Google Check service, which in short is a merchant facility for online transactions.

The immediate benefits are clear here, reduced development time and you get access to a bullet proof facility, but go a step further and use Google Spreadsheets Data API and you can easily hook-up a whole reporting and management system which produces Graphs on sale numbers and operational targets.

Another Cool combination would be to use the Gdata API to store the products online that you would like to sell. So all of a sudden you don't have to maintain your own database, Google is doing for you and somehow I think they can do a good job of it.

List of possible uses are almost unlimited, you could use blogger to data amongst a group of analysis, data which can read by a human eye as well as being machine readable. Anyhow as you can see the list could continue forever. As a thought exercise image a desktop smart client application that relied on web services for all it' s major components, how things would change not only in what we could do but also how quickly we could do it.

Software Architecture within a Commercial Context

Inspired by a recent post by Paul Reedman I was driven to make this response, before diving in let me go on record and say that having been a readers of Paul’s Blog for while now I usually find myself saying ditto to all his post.

But this one and in particular the responses which it generated has fired me into action.

The line "In the software industry it's all about writing code and getting a product out the door. Good design and architecture has disappeared." Sends the message, to me at least, that somehow we have sold off good design for the sake of money or commercial pressures.

I can understand those comments but I also need to say that is not way it has to be, in fact it is only that way in some organisations because us as a group of Software Architects have not been innovative enough to prevent this from happening.

My view point is this, Software is developed within a commercial context and the commercial model of supply, demand and free market forces needs to drive everything we do. Recent history has shown us this is a force that can’t be resisted.
So as Architects we need to embrace this reality, much like many of us have embraced change as a fact of every project we all need to embrace commercial constrains of time and budget and design around it.

Now that does not equal compromise rather it should cause us to innovate. Let me share some experiences here in short form, I will save the details for a book, or for the next time we have a drink together.

• Just Like Any Other Feature - Get the time and budget constrains into the project requirements and map the relationship between other constrains and these commercial ones.

• More bang for the buck – Everything needs to used more than once, write development documents that can be rehashed for user documentation, use API test suits as a basis for API Client libraries, practice OO reuse all the time. (Email me if you want more of these ideas I have hundreds)

• Less is more – Be strategic why spec two functions that have 70% overlap, give it one use case and extend it, same applies at implementation stage.

• Use a pattern – Patterns are distilled experience which is free and only have a positive impact on the project, so understand them and use them all the time.

• Parlay It Up – Stop looking at projects in isolation, ask yourself what is one thing we can do that will have less than a 1% impact but give us some value that we can use in the next project. (Poor man’s framework and code base)

• Don’t remake the wheel. For the pride, if there is a third party component, server, application, API, whatever that can help you deliver; trade some budget to save some time. Clearly do this with care; it can work out if you do your homework.

• Show me the Money – Releasing early and releasing often not only keeps a client happy but can work to simply your project. Something magical happen you make the client live and breathe an early version of the application. They start to discover how they can optimize the functionality and this can highlight the useless stuff that can be cut.

Now that I made all the motherhood statements let me hit with some hard realities. You cannot change the laws of physics; total project budget divided by time constraint divided by the number of plan iterations will always limit what one can achieve.
The defining factor of a software architect and where the art comes into it is how much you can achieve with what you have to work with.