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.