Desire to work with innovative or upcoming technology with or without any p-o-c.
An architecture may conform to an architectural style.
Focus on significant elements.
An architecture is influenced by its environment.
Architecture in adopted technologies or framework -
For example CORBA, J2EE, JSLEE, ACE, .NET and so on…
Stakeholders needs –
The end user is concerned with intuitive and correct behavior, performance, reliability, usability, availability, and security.
The system administrator is concerned with intuitive behavior, administration, and tools to aid monitoring.
The marketer is concerned with competitive features, time to market, positioning with other products, and cost.
The customer is concerned with cost, stability, and schedule.
The developer is concerned with clear requirements, and a simple and consistent design approach.
The project manager is concerned with predictability in the tracking of the project, schedule, productive use of resources,
Client is technical – wants to go for a particular technology or a particular framework, design patterns etc.
Desire to work with innovative or upcoming technology with or without any p-o-c -
Usually true for a new enthusiastic architect/designer.
An architecture may conform to an architectural style -
Pipes and Filters, Data Abstraction and Object-Oriented Organization, Event-Based, Implicit Invocation, Layered Systems and some more....
Focuses on significant elements -
Significant elements are those that have a long and lasting effect, such as the major structural elements, those elements associated with essential behavior, and those elements that address significant qualities such as reliability and scalability.
An architecture is influenced by its environment –
A system resides in an environment, and this environment influences the architecture. This is sometimes referred to as "architecture in context." In essence, the environment determines the boundaries within which the system must operate, which then influence the architecture
Not Casting Your Net Widely.
Just Focusing on Functions.
Forgetting That It Needs to be Built.
Lack of Platform Precision.
No Disaster Recovery.
Scoping Woes -
Many projects end up being doomed to failure before they’ve really started, simply because their scope was wrong.
Not Casting the Net Widely -
A related mistake that many of us have made is to focus on just a couple of our system stakeholders – classically the acquirer (who is paying for the system) and the end users get all of the attention. But what about development team, DBA, System administrator and others???
Just Focusing on Functions -
Usually a new architect/designer make this mistake.
Forgetting That It Needs to be Built -
If the design or the technologies we use are too sophisticated or immature, then we may be jeopardizing the architect/system. However, when we do this, it’s often worth asking ourselves which stakeholders our new design is really serving – the answer may well be ourselves, first and foremost (and possibly the development team).
Lack of Platform Precision
We need Unix, Oracle etc etc. NO!!! Be precise please.
Security Lapse -
Call expert. Implement standard security algorithm and not custom made.
No Disaster Recovery –
Many systems reach production without major mishap and manage to run successfully there for years, without any significant interruption to service. Others aren’t so lucky and suffer some sort of major failure involving entire system recovery a number of times during their operational life. Are we ready for such disaster?
Note: Below points are too veiled to be overlooked…even by an experienced architect/designer.
Unnecessary complexity -
For example - The customer wants a cup of tea, and we build a system that can boil the ocean.
Don't try to solve problems that don't need to be solved.
Don't worry about the future until you're not sure that you can survive the present.
Don't build things for the fun of it.
The organization's health is more important than the developer’s desire to play with the latest whiz-bang tool or technique.
Don't add risk without a compelling and measurable benefit to the project.
Don't invest in the future if your current project is in trouble.
Architectural Mistakes – SOA An Example
Service-oriented architecture (SOA) is an architectural style where existing or new functionalities are grouped into atomic services.
These services communicate with each other by passing data from one service to another, or by coordinating an activity between one or more services.
Requirements for SOA
Requirements for a true SOA
Interoperability between different systems and programming languages
Clear and unambiguous description language
Retrieval of the service
Misnomers & Mistakes Done with SOA
Everyone is talking about SOA, probably it’s the best for architecting a solution
SOA advocates heavy usage of patterns allowing the application services to be extremely re-usable. So I would use patterns across my architecture and design
I will make SOA and external systems would be able to discover my application services and use them. – What would happen to my legacy systems that are socket based?
With a SOA, my development team would always achieve shortest time to market while introducing new features, and it would also keep the business and the application support staff happy. – It really depends on the way SOA has been implemented!!!
Equating SOA with Web Services - Web Services are just one of the mechanisms for exposing, requesting and consuming services. Other mechanisms include ESBs, REST, etc.
In a SOA everything is exposed as a service – Not a very accurate statement to make.