Capabilities that an Architect picks up

One starts of as a learner of technology
One masters programming
One masters problem solving
One gets hang of technologies - to know trends
One if able to apply technologies to solve problem
One is able to conceptualize big (in scale) solutions
One then learns to develop a plan for achieve solutions - what is the order of building pieces
One learns to bring in business into picture - buy vs build
One learns to adjust plan as business situations change
One learns how to lead execution of an architecture
One learns how to sell architectural proposals
One learns how to teach
One learns to lead and facilitate - let everybody realize their potential

My belief is that there are more of such learning steps... rest of mountains in the journey would be visible once one crosses these ... i am still stuck in one of the mountains ...A lifetime is not enough to master all this ... that will keep the excitement in the journey!

Troubleshooting JBoss HA

JBoss HA relies on JGroups for communication. It is very easy to work with, but if it doesn't it gets little difficult to troubleshoot. This is what i realized last week when i tried to set it up on two machines. Here are the steps you can follow if you are stuck:

1. Check whether multicast works - http://www.jboss.org/file-access/default/members/jbossas/freezone/docs/Clustering_Guide/4/html-single/index.html#id3016498
Want to read some theory on multicast - http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Multicast-HOWTO.html

2. Check if JGroups is able to establish communication channels - http://myt.ag/URLWeb.aspx?email=steve%40fooworks.com&url=http%3a%2f%2fwiki.jboss.org%2fwiki%2fWiki.jsp%3fpage%3dTestingJBoss&sn=

3. Enable logging in JBoss to see more info - http://www.jboss.org/community/docs/DOC-9164

4. Make sure that you are not booting JBoss with -b 0.0.0.0. Give IP address of machine instead of 0.0.0.0

Three types of architects

Enterprise Architect
Infrastructure Architect
Software Architect

from : http://msdn.microsoft.com/en-us/library/cc431351.aspx

Another one of Architecture

Architecture is user experience
Architecture is negotiating and bargaining
Architecture is technology
Architecture is form
Architecture is communication
Architecture is artful
Architecture is agile
Architecture is the creation of a better world

from : http://msdn.microsoft.com/en-us/library/cc304371.aspx

Architecture of a process

Evolution is a process that makes lot of us wonder. In the beginning there was a condition created ,that included lightening, that resulted in amino acids. These then got together causing proteins and cells to be formed. And from then on two steps followed continuously - mutation and reproduction. Huge number of repetitions of this caused such a variety of species, human being one of them. If God designed the process, He probably did not design it with Human Being or any other specie as the culmination. He designed a process that would go on and improve. Wonder what would happen if any one of this steps was missing the process would not yield. Lot of repetitions of this step - much like fractals - causes results that make us wonder. It would simply be not possible to design human specie as an independent design.

Assume that God was in the process of designing this. In the first release of design He would make reproduction as primary requirement. Once cells were designed, He would have then thought of bringing change in the cell to make evolution possible. Mutation is also very carefully designed, because any mutation we try artificially results in certain death. As a software engineer i am inclined to think of God writing a program (in assembly language with UAGC blocks, a DNA being a module). Every time we muck with the code the program fails. In a computer program as long as i write syntactically correct program, the program will run. It may not achieve anything meaningful, it may not terminate but it will run till an 'exit' is called. God's designed the virtual machine (that runs the program) that terminates syntactically correct programs. This deviation from randomness to get optimal results is also evident in "scale free design - http://www-news.uchicago.edu/releases/06/060807.networks.shtml.

Architecture is not just a structure that one sets in the beginning and then it stands touched. It is more like a process. Once the principles or say fundamental steps are followed over years product gets better and better. If Amazon asks its engineers about what happens millions of people access a program, it is an example of architecture of a process that results in scalable systems. I would say REST is also another example of same. SOA Choreography gives a base wherein one can create such an architecture.

Choreography and Orchestration

... I thought, described the same concepts. Here is what people are talking about,

Orchestration always represents control from one party's perspective. This distinguishes it from choreography, which is more collaborative and allows each involved party to describe its part in the interaction.

In orchestration, there’s someone — the conductor — who tells everybody in the orchestra what to do and makes sure they all play in sync.

In choreography, every dancer follows a pre-defined plan — everyone independently of the others.

Orchestration defines procedure and Choreography defines protocol.

Orchestration is generally a full-on execution mechanism for recursive composition of services (aka WS-BPEL). Choreography describes the observable behavior that makes up a contract between a set of peers. It doesn’t say how it is to be achieved just what can be observed. Orchestration is much imperative and choreography declarative. They can work hand-in-hand.

What is the relationship between choreography and web services composition? ... A composite service is a system that arranges existing services in a workflow of some sort (or process if you want) and deploys this arrangement as a service of it’s own. The added value of this system therefore is a previously non-existing functional construct. The key point is that the composite service is indeed a composition and not a simple collection of existing services and that within the composition the service invocations must! be coordinated, e.g. through choreography where the control is centralized. So choreography is a mechanism for coordination (control) in a composite service.

What is Web Services Flow Language? WSFL supports two types of composition and choreography: Flow models: describes business processes; Global models: describe overall partner interactions. Flow models - Describe how to choreograph the functionality provided by a collection of Web services to achieve a particular business need Global models - Describe how a set of Web services interact with each other. ... it was mentioned somewhere that WSFL is superseded by BPEL.

WebService composition can be achieved view two patterns - hierarchical and peer-to-peer. Hierarchical interactions are often found in more stable, long-term relationships between partners, while peer-to-peer interactions reflect relationships that are often established dynamically on a per-instance basis...

Beauty in Software Architecture

Some of the architectures look beautiful to me. I wonder what are some of the properties which make a Software Architecture beautiful and even if not beautiful ... very attractive. To be attractive something should be easily understood. Fewer concepts, fewer new concepts and simpler relationships between those concepts would constitute simplicity. If something is complicated you have to force your mind to understand it and chances are high that it will not appear beautiful unless the payoff of effort is higher. Later brings us to "surprise" aspect - core of Application Server like JBoss has nothing to do with applications or JEE, it is JMX, interested in only starting/stopping services.

Then something that brings a wow is, how much thinner the software can get. A big application server can have a microkernel only 50K size. That is beauty. For something flexible enough to grow very very big and shrink very very small, the core pattern has to be simple. And that pattern has to be repeatedly applied. And with zero exceptions. That catches attention.

And finally, recurrence. That always is attractive. The services of JBoss are MBeans loaded by core, but core itself is MBean. All this takes me to Mandelbrot ... aren't principles of what is beautiful same?

Model Execution Platform - build vs assemble

As one decides to embark on the model driven development journey, one has to answer how a platform would be created that would execute the model. By executing the model i mean, converting it into a runnable code or interpreting it. Performance is something that i have not personally seen examples of in MDD. Till we really get a hand on performance it is difficult to decide which way one should go - build or assemble. Given that performance goals are honored in both approaches, what would be next deciding factor.

Building whole framework from scratch is just impractical given time to market. Assembling open source and commercial softwares doesn't work as these things do not work seemlessly. There are MDD platforms being built, which i still see organizations will not bet on.

The approach then some cautious organizations take is to take open source / commercial products and write code to create the platform. And slowly one goes overboard developing their own versions of what is available, just because as implementation gets deeper the stakes get higher and requirements from new component increase.

There is one bottleneck which is increasingly becoming important and it is learning curve. Learning curve needs to be managed as one builds proprietory stuff. Learning curve is important for following reasons,

1. Small learning curve means higher productivity. There is more room left in ur RAM to look into other things than managing your platform.
2. Faster ramp up of new hires means tolerance to churn.
3. Ramp up experience also ends up positioning the platform. An easier platform gives an impression of well thought out and well designed platform.
4. Smaller learning curve might be the only way as systems become complex.

Now smaller learning curve can be achieved by either hiding details from people or using well documented, well designed components. Hiding details and presenting a good front to system take lots of effort not only in development but maintenance too. Well documented and well designed compnents that confirm to standards shorten the learning curve. Open source components have the benefit of good documentation and almost always adherance to standards. But then if u get a similar component for money, chances are higher that it would be good quality. But then documentation is always more for open source.

Model is the Front Gate to your code

Treat model as the front gate to you Code House. A guest/newcomer to your house would enter through the front gate, will be welcomed by the garden on both sides, will be guided by the road that takes her to the main door. And he will ring the bell, will find a drawing room etc. and then you take her around the house.

Contrast that with current state with out of sync, half finished design documents, which are like backyard entry. You don't know which room will u land up in, and you don't know how many rooms you would have to navigate urself till you find someone who can show u around. And all other ways are like entering through windows, roof or chmineys.

This thinking will go a long way in making your code more maintainable. Besides cost benefits (less learning curve and lesser bugs), it has soft benefits like developer morale. This motivate s developers to innovate. So, use Models whereever possible just to organize code, just to create that front door.

Domain Driven Design and Model Driven Design

Here is a article that talks about both,

http://domaindrivendesign.org/discussion/blog/evans_eric_ddd_and_mdd.html

While MDD can be applied with being at distance from the domain, DDD takes the concept further saying that Domain should be at the centre. And then MDD should be applied to different pieces of software.

UML as a modeling language

UML has emerged as the language for modeling. Its the common language spoken for communicating by software developers. It is very good for modeling a software system and is mostly targetted towards software engineers. But, modeling a system is mostly the domain of end-user or domain expert. Then comes a need for defining a language for the domain which is to be modeled. UML provides for profiles, it is like defining a language for modeling.

That is where i question. Are we not using UML for sake of using? How easy it will be for domain experts to model or even understand the models in created with UML profiles? The notion of stereotype is understandable for a software engineer who treats class concept as more fundamental. But a domain expert doesn't need to know what a class is. I guess its because of this that we have languages like RDF, OWL to model resources and real things. These languages are specifically designed for the domain they will be used for. Ofcourse you can always create a UML model for anything that is described using these languages and it should be done if we have enough toolset to create products from UML.

If you have to describe a banking system you need concepts like Account, Customer, Interest etc. and a way to use these to describe a particular banking system. Domain expert doesn't need to know any more. Once done, this may be translated to UML models which could lead to the product.


Modeling is human centric and needs to be simplified for that particular use.

Abstraction and “What”

If you look at way our software programming has evolved abstraction would be the word that ties most of it. We started with assembly language with a linear sequence of instructions, abstracted out concepts like blocks of code into functions and created languages like C. We simulated concurrencies with another abstraction threads. Object orientation helped us manage much more complex projects by taking away focus from problem solving to describing a system. It has been a journey of abstracting out concepts and the direction is What. With every abstraction we are coming closer to specifying “what” we want than “how” it will be done. Although both are important, “how” is reusable much more than “what” and we have done a good job of “how”. And it will always awe us the ways in which we use “how” and permute different “hows” to create different “whats”. So, there will always be much more “whats” than “hows”.

Highly specialized DSLs (Domain Specific Languages) are being used nowadays and this brings us closer to describing (“what”) the system with minimum effort. This was the reason that we developed languages like Mathematics. I remember my first job involved creating simulators. Mathematical models of a system element was provided and then any system with any combination of system elements could be modeled and simulated/solved. We are following the same path to handle complexity – the model way.

Highly specialized modeling language should allow domain experts to define the “what”. Software should be then written to interpret or consume in some way that model to realize the “what”. This means software development should start with defining the modeling language and then should branch onto two tasks. One to develop the software for modeling language and other to define the “what” using the modeling language.

The “whats” will always change as change is the only constant atleast in this real world. If we develop software targeting at “what” we will always create software that will age, that may not satisfy the “what” in the first iteration as the “what” got changed by the time product was out. At times “what” is not definable in one shot, it evolves and can’t be verified until the product is made. The modeling language would more or less remain constant, is very well defined and opens options to multitude of possibilities.

Infact the “whats” should be in public domain, it should be shared and jointly owned. The software that would realize the “whats” may be owned by companies so that better realizations are always created.

Is Model an end?

Creation of Universe is an example that fits the current discussion. The big bang model says that it started with an explosion, intelligent design points at a God like entity. These models can explain the current observable phenomena. Is it end of the analysis?

Or because we have multiple models to explain current situation, and we believe that there has to be only truth, we should dig deeper to eliminate models. That means we have to try to play with model and predict some other things beyond current observations. And look for inconsistencies with existing models. And then choose the best model and live with it till an observation invalidates it or a new model superior to it is proposed.

But if there were no models would u still do all this. Well, there is no need for all the applications of it, but to believe in it we would still like to dig deeper. Validate it for extreme situations that are of no immediate necessity. And one could say that understanding is an end, so model is not an end by itself. That is, models should be proposed, evolved, scrapped, recreated for the end goal of understanding.

What do i mean by model?

By modeling i mean identifying and specifying concepts and relationships for the domain which it is modeling. Modeling a domain not only represents the collective knowledge, but aids understanding and in advanced usage can help prediction. Most of our science and mathematics is aimed at modeling the world. What is newton's gravitation law but a modeling of real world for its mechanical properties.

Scientific experiments start with an hypothesis and then verify the hypothesis but a model. It identifies the concepts that are relevant to experiment, it declares relationship between concepts. The aim of experiment is to verify the relationships.

Modeling is common to many domains and current movements in semantic we are about modeling domains so that software can process it. It is with this thought that i start this blog.

Small teams vs organizational uniformity

Companies like Google have small teams that use their own set of technologies and churn out products faster. And this had always worked. And there are companies that prefer organizational uniformity. If one builds a MDD platform, most probably one is going with organizational uniformity.

What i have seen that standardizing on technolgoy and platform tends to cut the innovation. Broadly two reasons,

1. When new people come onboard, they have new pair of eyes. Given a chance that they use what they know and develop what they see lacking in offerings, innovation is higher. In uniformity based environments they end up spending time learning (and unlearning what they knew) and most of the time end up as good as (or as bad as) the existing employees.
2. This might look as not that important, but my experience says it is. Given directions from top, right at the time of joining sets up "take all" attitude in people. They stop questioning or thinking out of the box. Not too many things should be etched in stone.

But the maintenance of a uniform platform out weighs other options. And what needs to be managed is again the learning curve.

Technical hierarchy/path

Interesting to know the how the world is seen from different points in a technical hierarchy/path.

What does a Technical Architect do next?
What does a Chief Architect do next?

Types of Architecture

Typically a big organization has multiple divisons/departments/businesses in it. There is a architecture applicable to organization as a whole to align the business strategy and IT investment. And then we have two more architectures, giving some more detail at each level. To me it looks like that it is intent and intended audience that decide what information goes into these architectures.


Enterprise Architecture could consist of four sub-architectures.



If you have some more hunger left for organizing the stuff a army of architects do at any company, read this interesting blog - Making sense of architecture standards.

Are you in SOA world?

Yes, if you understand and speak the terms above. If no, read a very high level document on SOA -
OASIS Reference Model for Service Oriented Architecture V 1.0 - Official Committee Specification approved Aug 2, 2006. (Normative PDF)

This document talks of reference model, reference architectures and concrete architectures and gives their relationship by way of simple examples.

Why does your business need SOA?

Your software have stood the waves of technology change. And if you were not careful it has withered and your architects make a call to improve it bigtime to improve maintenance cost of old software. What worries you is “Let’s change and try a new approach” approach. There is complexity in your software, part of it is inherent in the domain and part of it is the way software is written. Most of the time when complexity grows enough, technologists wish to try a simple overlying approach, only to find out that some complexity cannot be done away with. You SOA thoughts could be started from your IT department or better you business guys. In any case it is good to have an overarching approach.

You could follow Seagull Software Five Point Plan to SOA (http://www.contactcenterworld.com/view/contact-center-news/SOA-Migration-Must-Be-Driven-By-Business-Needs-And-Not-Technology.asp) :

1. Identify your business pain points and the services you need to offer
2. Forget 'rip & replace'
3. Remember 'wrap & adapt' to service-enable underlying architecture
4. Understand the technology - but don't get bogged down by it
5. Adopt a staged approach to SOA

The first step is to understand business needs. Cutting total cost of ownership is also a business concern. So, it is good for you to find a higher level case for SOA without getting into technological aspects. Next section gives a list of probable causes so that you can think on these lines. Before that we have here some examples of reasons that various industries have.

What are some of the market forces leading your industry toward SOA? (http://www-306.ibm.com/software/solutions/soa/businessleaders.html )

Automotive:	Growing need for multivendor in-vehicle systems/software integrationShift of design and manufacturing among automotive value chains
Banking:	Continued regulatory involvement with added pressure on costs and integration
Electronics:	Disparate systems used in design, development, manufacturing, marketing, and sales
Financial Markets:	Regulatory compliance and automation of trading
Government:	Need to improve oversight, accountability, and compliance
Healthcare:	Increasing pressure to integrate payers, providers, and government agencies
Insurance:	Enhancing customer satisfaction and increasing up-sell/cross-sell opportunities
Retail:	Customize the consumer experience and real-time product availability
Telecom:	Create and connect applications with less development time, expense, and expertise

1.1. Hide organizational boundaries

Collaboration is in and internet is being used to build networks that are far more value adding. The softwares that a business uses have to work with the network partners. And fewer things can cross boundaries, definitely not design guidelines etc. Its difficult to even adhere to interfaces forget platform.

Even inside one company things get complex. If one is building a complex software across multiple teams, one need loose coupling and as less as possible design constraints on architecture. And if you are a company with multiple departments and you have some history, you have a complex situation. Your departments in past have bought different applications so diverse (with totally different architectures, platforms etc.) that they always worked independently with humans acting as integration points. And your departments wish to buy new softwares to enhance the existing functionality. And you start suffering from “How do I make all this work together?” syndrome then SOA can help you a lot.

1.1.1. Across companies

SOA provides you a standard that you can agree and then forget. The toolset in the market will help applications integrate. And you have series of options if you needed visibility into what and how the applications were communicating. SOA perhaps is designed for this kind of scenario.

1.1.2. Intra-company

You can have some sleep at the expense of some performance, which is not really considerable in some applications. This relieves the architect from worrying about yet another architectural concern – will it run together?

1.2. Bridge legacy and new systems

You have this legacy finance system which you wish to integrate with your new online marketing software. The two softwares are similar in only that they are software, rest all is different. The very thought of integrating these raises your hair. You need a new abstraction where you take these two systems a level up, call them as services and them at that higher abstraction you design the integration. All the while being supported by WS integration toolset.

1.3. Bridge current and far future systems

You had an experience like above and you are building a system which you feel that few years down the line will create the same hair raising experience. You wish to be pragmatic and you thing SOA is the abstraction this industry needed and you jump on the bandwagon.

1.4. Design for quality attributes

Some time there are architectural limitations that are put by architects to simplify the architecture. Architects and designers can then focus of other concerns that are of higher importance.

1.4.1. Design of unavailability of sub-systems

By allowing systems to be loosely coupled and lowering the availability of sub-systems, design is eased. One has to expend extra effort in designing highly available systems and this cost could be saved.

1.4.2. Design for ease of adding new sub-system

You have a situation where you are building a piece of a huge system and you either don’t any idea of how many other pieces will come in future or you do not wish to worry about them now. You design the system in min with integratability as a quality attribute.

1.4.3. Paradigm for robust design

Thinking of software as service helps in creating robust systems. With a clear contract – the inputs and outputs of a service and no assumptions on availability of service, the consumer of service can build in robustness instead of falsely assuming availability.

1.4.4. Extreme Rapid Application Development

You have an application team and a business logic team. Your business logic team is concerned with developing assets that your application teams can use to quickly create an application. For example a address validation and correcting functionality was built by business logic team by guessing its need. The application team wishes to use same functionality in multiple applications. And many times application design is dependent on what functionality is present, not only from time to market perspective but the fact that application developers are not aware what can be done now, which was not possible few years back (also called Technology Driven Innovation). You need a component model to manage these assets and SOA is not bad.

1.5. More reading

Service-oriented architecture: A practical guide to measuring return on that investment - http://www-935.ibm.com/services/us/index.wss/ibvstudy/gbs/a1025716?cntxt=a1002583&

Changing the way industries work: The impacts of service-oriented architecture - http://www-935.ibm.com/services/us/index.wss/ibvstudy/gbs/a1025932?cntxt=a1002583&

Blueprint for supply chain visibility: Service-oriented architecture can help drive agility, supplier collaboration and demand-driven replenishment - http://www-935.ibm.com/services/us/index.wss/ibvstudy/gbs/a1028723?cntxt=a1000453&

SaaS, SOA and Cloud Computing - in one breathe

You are a finance manager of small company. You want to give your employees a payroll portal, where they can see breakup of their salary, choose various tax deduction schemes and provide information like bank accounts where salary is to be credited etc.

In earlier era you would buy a software payroll application, buy hardware, hire IT staff to run the application - and all this after very very careful planning. The next version of application comes and you have to plan the migration - safe and non-disruptive. Too much of cost and hassles.

Well, in current era, you would go to a company, say XYZ Payroll and buy a service. The application is hosted, managed and owned by XYZ Payroll. You just get a company setup in it with accounts for all your employees. The data is definited owned by you, but it lives in XYZ Payroll's data center. And you do not pay upfront all the cost, but you pay for subscription - 'Pay as you go' approach. This is SaaS. ASP and onDemand has been precursors of this acronym.

XYZ Payroll doesn't do this just for you, but it has series of clients with same needs. It's software could be multi-tenant or it might host single instances for clients. In either case it benefits from economies of scale, better in former case though.

Now let's say XYZ Payroll doesn't want to invest in hardware and platform management - provisioning systems, managing them etc. So what XYZ Payroll does, it goes to ABC Computing Services and hosts its application there. ABC Computing maintains a huge hardware and has gained lot of expertise in maintaining it. It also provides platform level software services like storage etc. And it gurrantees some availability. What ABC Computing is offering is utility computing, cloud computing, grid computing etc.

What if you were a developer of the application that XYZ Payroll is providing as service? You could design that in traditional way or you could design it in Service-oriented way. That is you build it as a service, using multiple services like say HR&Benefits, Tax etc. This type of Architecture is SOA.

SOA is all about how software is structured and SaaS is all about how software is used.
Bradley F. Shimmin
Principal Analyst of Application Infrastructure, Current Analysis LLC.

Architect defined by skills

Joseph Hofstader discusses the skills that Architect role demands - We Don’t Need No Architects.

There are four of them of categorized into two phases of software development - problem definition and solution development,

Problem Definition

1. Domain - understand the domain well enough.
   


2. Conceptual - is able to conceptualize and abstract.
   

Solution Development

1. Technical - understands technology well and is always updated.


2. Pattern - has rich pattern vocabulary, is able to apply them to design and use them to discuss intelligently the solution.
   

Architectural Styles and inspirations

The road of abstractions has infinite milestones. The infiniteness is a consequence of human thought, which finds patterns, commonalities, higher plane of unification at almost infinite levels. This writeup is about the abstractions as far as software architecture is concerned.

In "Architectural Styles and the Design of Network-based Software Architectures" thesis, author talks of Architectural Styles.

An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.

The styles are categorized into five categories,

1. Data-flow styles

• a. Pipe and Filter (PF)
• b. Uniform Pipe and Filter (UPF)

2. Replication styles

• a. Replicated Repository (RR)
• b. Cache ($)

3. Hierarchial styles

• a. Client-Server (CS)
• b. Layered System (LS) and Layered Client-Server (LCS)
• c. Client-Stateless-Server (CSS)
• d. Client-Cache-Stateless-Server (C$SS)
• e. Layered-Client-Cache-Stateless-Server (LC$SS)
• f. Remote Session (RS)
• g. Remote Data Access (RDA)

4. Mobile code styles

• a. Virtual Machine (VM)
• b. Remote Evaluation (REV)
• c. Code on Demand (COD)
• d. Layered-Code-on-Demand-Client-Cache-Stateless-Server (LCODC$SS)
• e. Mobile Agent (MA)

5. Peer-to-Peer styles

• a. Event-based Integration (EBI)
• b. C2
• c. Distributed Objects
• d. Brokered Distributed Objects

However this is not the only abstraction. Lifetime Objectives and Lifetime design is another abstraction practiced by some. These are set of objectives and architectural concerns that are assumed to be true for entire lifetime of the architecture being created. Could we categorize architectures based on this? This is for a future writeup.

In many cases and mostly with me, the architecture comes with a simple underlying thought/strategy. A very simple statement that defines not the architecture but the direction of architecture. Let me call that as architectural inspiration. This is an overly simplified of universe in discourse, the domain world. Some of the architectural inspirations are, (replace world with everything)
1. World consists of objects. Objects have behavior and data.
2. World is made up of resources. Resources can be identified by URIs and accessed by a protocol.
3. World is only about services. Discover a service, use it and forget it.
4. World is a language. The language is understood by a platform and job of software development is to describe problem in the language.

Selection over perfection

Many of us know that a complete solution (design/architecture) to a problem does not happen in one day. It takes months and years for a great architecture to be done. And what has hurt software engineering is to go extra mile for perfection. It is very interesting to take some ideas on ways to think or be creative from a poet - http://tesugen.com/archives/02/09/lowerstandards .

In the book Art & Fear by David Bayles and Ted Orland, is a story about a university pottery class that were broken into two halves: one half was told that their grades depended on the quality of a single pot handed in, while the other half should get their grades based on the total weight of all their semester’s pieces (50+ lbs was an A, 40-50 lbs a B, and so on).

The best pieces all came from the latter half of the group – the ones “graded by weight”. Blog uses this example to illustrate how a poet experienced a shift in his writing as he began to write one poem a day, instead of working on a single poem at a time, revising and polishing until it was good enough. Basially prefering a selection from his 100s of poems than perfecting few of them. Instead of making one long continuous mistake do once-a-day. Lower your standards and get things out - this way you are training your brain to be better each time you do a selection.

Architect Oryzus - three pillars of architecture

Just read a very very interesting article - The Social/Psychological Side of Software Architecture (my talk at reboot7) (http://tesugen.com/archives/05/06/reboot7-talk). This article brings some more clarity on oryzus part of architect's role.

The author argues, there are three pillars of architecture,

1. Technology
2. Social
3. Psychological

The technology aspect is about describing the internal structure of software system.

The social properties of architecture are about making everybody get the same image of the architecture. Somewhere, filmmaker Francis Ford Coppola has said that the difference between a good and a bad movie, is getting everyone involved in making the same movie. Social aspects deal with memorability of how things work.

The psychological pillar is closely related to the social one. Where the social pillar of software architecture concerns architectures evoking similarly-organized mental pictures, the psychological pillar concerns architectures that stick in the minds of the individual team members. What becomes important is the process of getting to architecture that just the goal :architecture.


It is also interesting to know that buildings take on shape after they are built.

‘Porches fill in by stages, not all at once you know.’ The architect was responding to a talk I gave at a builder’s conference. ‘The family puts screens on the porch one summer because of the bugs. Then they see they could glass it in and make it part of the house. But it’s cold, so they add a duct from the furnace and some insulation, and now they realize they have to beef up the foundation and the roof. It happens that way because they can always visualize the next stage based on what’s already there.’

Author also talks of user and UI being an important part of architecture. In most of the definitions of architecture user word doesn't appear.

Less is More with Minimalistic Architecture

Read more here http://www.bredemeyer.com/pdf_files/MinimalistArchitecture.PDF

Architecture is equated to Control. More of it causes inefficiency. It should be enough to maintain focus.

Architect Reloadus and Oryzus

Martin Fowler discusses two different types of Architects, http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf

Architecture is decisons made that are important enough for everybody to know. This boils down to Scope-Impact model.

Reversability is another concept introduced there. Due to lack of reversability of certain decisons, these should be taken early on and are important enough to be part of architecture. The article argues that architect should try to avoid irreversability.

Recipe to prepare an Architect

This is how the job definition of Architect evolves. Multiple cooks in the organization add their own spice. The end looks like a recipe which has everything but taste. It is perfectly alright to assume that an aspiring Architect is an accomplished engineer. Then he/she should be able to technically look at any software from multiple levels -40,000 ft to ground level and should be able to do that effortlessly as an eagle would. And look forward in time.
Assuming all this is there, he/she should then have business acumen. To understand business and provide strategic inputs to it.
Between these two is a wide gamut of Leadership. He should be able to motivate technical people ... take the teams through different paths to reach the destination. He should be good at communicating the conceptualization, manage interests of all stakeholders.



But most of the architects are good in one or two of these areas. And to do justice to any one of these is itself a commendable task. Also, many times the company/product/situation demands only a subset of it. But the recipe is still open for someone to add new spice. Soon someone will end up listing enterpreneurship as key architect skill.
There is a need to divide Architect role into multiple levels and make the transition from an experienced engineer to architect little easier than it is. A quantum jump is not good for someone who has crossed it and someone who has given up crossing it.

What is Architecture?

Architect is defined by Architecture
Architecture is defined by architect.
Architect owns architecture and whatever Architect creates is Architecture. Read more here,

http://www.bredemeyer.com/whatis.htm

This gives some vague idea about Architecture. It defines it as a set of very high level technical decisions which are systemic and have a high impact. So scope and impact are the two dimensions on which the first quadrant will be the archiectural concerns.

Scope-Impact

S    |             |  Architectural concerns
C    |_____________|________________
O    |             |
P    |             |
E    |_____________|________________
                IMPACT

But there is one more dimension that some of the definitions revolve around - its the life of decisions. If the decisions live through the life of the product, most likely they will be architectural. This also means that these are decisons that are almost irreversible. Changing them is very difficult.

Architectural decisons are typically taken early in project lifecycle.

The above two points again tie into Scope-Impact model. Because of big scope and high impact the decisons are important enough to be taken early on. And the importance also guides the reversability.

Ofcourse each of these definition has exceptions. Once we have architecture, important thing is that Architect owns this. Own means - create, make changes and discard/replace at appropriate times.

For budding software architects

A time comes in life of a software engineer, when he can't remember last time he debugged or fixed a bug. Design and coding are still part of the job, but he has been leading projects. And suddenly he begins hearing about next quantum jump called architect. It is like an electron moving from inner orbit to valence orbit, ready to join the club which will create semi-conductor properties in a silicon.

What is not very clear is the meaning of quantum jump? More unclear is the path to becoming one. This blog is about throwing light on various aspects of architect.