I love the concept of immutable microservices. In short, it means that every component of a system is designed and packaged as a microservice and those components' configuration is never changed. This means, virtual servers, virtual switches, databases, applications, etc are all versioned and if a configuration change is required, a new copy of it is deployed on the correct version.
For this to work, the organisation has to understand a few base patterns:
When developing a new system, companies often view go-live as the last step in the software development life cycle. This causes a mental disconnect in people’s minds having on the one hand the SDLC of: inception, design, implementation, installation and on the other hand the production support. In the modern time this mindset is no longer efficient enough, with companies moving towards a DevOps and NoOps operational strategy instead.
I’m proposing that regardless of which operational strategy companies use, they should also adopt a “Go live first” approach. By this I mean that any project to develop a new system or replacement of an existing system should begin by installing a placeholder for the system into production and holding a go-live event for that placeholder. This means, the system has not been developed, the business requirements are not yet collected. All that is available is the high level vision of what the system will accomplish and a placeholder. During the "go-live first" event the management backers of the project explain the vision of the project to the future users of the project and show them how to access the placeholder and how to contact support about the system.
The business analysts then start writing business requirements and system architects write designs, but instead of writing it as if for a future system, they write it as changes to an existing system. The operational staff support the system as they do for any other production system.
The benefit of this is that it will stop companies from building development support systems that are not used to support production system. It will coordinate all IT development into focusing on the productionisation of the systems and how to support it while it is being changed. It will encourage IT staff to be more closely aligned with business and it will enable business people to think and act with more agility.
Software development is the process of enabling users to
communicate instructions to a machine and have it perform those instructions as
expected. More generically, software development is the action of building a communication
channel between a user and a machine.
This communication between user and machine closely follows the Berlo SMCR model of communication as explained through the following example:
a. Source – The user has an intention to have the machine perform an action.
b. Message – The instruction which the user wish the machine to perform.
c. Channel – The software accepts the message through a user interface and translates the message into the relevant format for the machine.
d. Receiver – The machine receives the translated message and acts on it.
a. Source – The machine has succeeded or failed to perform the instruction.
b. Message – The feedback on the execution of the instruction.
c. Channel – The software translates the feedback and presents it to the user through a user interface.
d. Receiver – The user understands the feedback presented.
Note: Software systems may consist of a chain of channels, each being a receiver of a message and a source for the next link in the chain. As long as instructions originate from a user and gets executed by a machine, the above process holds for each link in the chain as well as the chain as a whole.
Software development is responsible for making this communication as effective as possible by limiting the translation failures (noise) at every step. To accomplish this, a software developer must optimize the following variables:
1. Understanding of the user's intentions and expectations
2. Understanding of the machines capabilities and language
3. Translation of the message into the machine's language
An enterprise system has many thousands of users and many hundreds of machines combined into one software system. This makes it near impossible for one person to optimize all 3 variables.
Would the employers rather have another specialist in a business field (of which there should be enough already in their business), or would they rather have someone who has the capacity to analyse and strategise and approach problems of all sorts encountered at the confluence between business and technology, someone who fits the parts together?
Very few EA architects would be able to create their own framework able to link the disparate parts of your business in a big picture. This is what you ideally want. But it's hard to find. You'll discover a lot of show off, ranting and hype.
You'll have to make sure that the architect understand how business parts and designs fit together in a blueprint or set of them. Ask them to show you a sample integrated blueprint.
The architect may document and design for you the many parts of an enterprise. But if you put them together would your enterprise fly same as an airplane does when you fix the parts together?
Enthusiastic: A passion for life, work, and EA goes a long way. Far too many architects are rendered much less effective simply due to a lack of enthusiasm in their communication about EA.
Technology-agnostic: Unfortunately, many strong technical people are also quite biased in their views toward vendors/products and tend to “go with what they know.” Architects must be vendor/product-neutral and maintain an objective perspective.
General in technology outlook: It is important to understand enough about the broad range of technologies that an architect can engage in discussion with technical experts and not be swayed by inappropriately biased personal agendas in technical decisions.
Well-respected and influential: Architects need the support of senior IT and business managers and the ability to influence them as well as the IT organization at large. Those that are already well respected and have influence have an advantage. New hires must establish this credibility early. It should be noted that influential persons are not always in management positions.
· Able to represent a constituency: Members of an EA team have a constituency - part of the organization they represent in the process. Some individuals are too focused on their own agenda to properly represent others. Although it is fine to assertively share an individual opinion, he or she must yield to the position that best represents and serves his or her constituents.
· Articulate and persuasive: Enterprise architects must spend substantial time communicating and educating. Therefore, it is important that they have the skills to clearly communicate ideas in a persuasive, compelling manner.
· Persistent: Enterprise architects are strategically inspired change agents. People tend to resist change (in most areas), and we certainly find this with the behavioral change being introduced by an EA program. Therefore, it is critical to be persistent in pursuit of positive transformation.
· Good at “helicoptering”: Effective enterprise architects have the rare ability to zoom out and be able to conduct a worthwhile discussion about business strategy with the CEO and, a minute later, be in a technical expert’s office with a zoomed-in mindset discussing technical details without getting lost.
· Strategic: Strategic ideas are, by definition, those that contribute to defining or fulfilling the transformations described in the business strategy of the enterprise while tactical issues pertain to executing well with operations. Architects must be strategically driven, while recognizing the need to have balance in the organization with effective, tactical operations.
· Focused on what is truly best for the organization (limited personal agendas): Although it is human nature to have a personal agenda, the best enterprise architects are leading or participating in an EA process designed to yield whatever will best serve the enterprise (even at the discomfort on one or many along the way).
· Knowledgeable of the business: It is important to avoid the trap of technology for the sake of technology. Enterprise architects are leaders and therefore must have a strong interest in and understanding of the business, its strategic direction, dysfunctions, strengths, etc. It is not good enough to be a superior technologist.
Able to facilitate: Enterprise architects are frequently counted on to facilitate content development meetings or lead subcommittees. In this capacity, effective group facilitation skills are important.
Able to negotiate: It is important to seek the win-win positions/solutions on issues as architecture content is developed. There are difficult decisions to be made. Emotion can get in the way. Effective negotiation skills are invaluable for peacefully resolving these situations with powerful decisions to benefit the organization.
· Focused on the long term: The idea is to take a series of short-term steps that not only deliver near-term value, but also contribute toward achieving a longer-term vision for the enterprise. This demands focus on identifying and driving toward that longer-term goal.
· Able to effectively use the whiteboard: Architects are visual people and tend to feel compelled to draw diagrams in their communication. Some people even like to use this reality in interview techniques.
· Able to lead: Taking the initiative to persuade, inspire, motivate, and influence others, plus the ability to make quality decisions with a high level of stakeholder buy-in.
· Able to be taught: It should be noted that a strong understanding of EA is not on this list. This is not an oversight. We have learned that if a person possesses all or most of the aforementioned traits, and he or she is “teachable,” then he or she can learn EA best practices quickly and rapidly become effective
Have the ability to conduct a worthwhile discussion about business strategy with an executive and, a minute later, discuss technical detail with an expert without getting lost.
Strategically driven, while recognizing the need to have balance in the organization with effective, tactical operations.
Focused on what is truly best for the organization
Effective group facilitation skills
Effective negotiation skills to peacefully broker powerful decisions to benefit the organization.
Able to take a series of short-term steps that not only deliver near-term value, but also contribute toward achieving a longer-term vision for the enterprise.
Lead by taking the initiative to persuade, inspire, motivate, and influence others to make quality decisions with a high level of stakeholder buy-in.
A: Agile. An enterprise architect creates an agile organization — maybe even with the help of the Agile Architecture method! But by agile in this context, I mean an inherent personality trait, the ability to move from business-speak one minute to geek-speak the next, for instance, or being quick to leverage the briefly exposed soft spot of a line-of-business manager that can be played to so as to build project buy-in.
R: Range. An enterprise architect, it almost goes without saying, can’t be solely invested in creating complex technical solutions and structured documents. That person’s range needs to extend to understanding the business. Dare I say, even to loving the industry he or she is in. And loving it enough to dig in beyond the systems requirements that drive retail supply-chain activities, for instance. And enough to stay abreast of overall industry trends and directions, emerging global challenges in the vertical sector, and the company’s strengths and weaknesses within these contexts.
C: Communicative. An enterprise architect cannot be the guy or gal off in the walled garden creating models and diagrams that are to be implemented by faceless individuals. He or she is the great communicator who facilitates IT and business alignment by facilitating and fostering IT and business interactions. And the enterprise architect must remember that communication is a two-way street: He or she must help lead the discussion as well as patiently LISTEN to the viewpoints of colleagues, customers, and partners – even when the conversation seems redundant or the answer seems obvious.
H: Holistic. An enterprise architect thinks holistically, about system design, problem solving, technical- and business-domain structures and processes … and the people who engage with them.
I: Innovative. An enterprise architect knows that the work is about more than helping the business do what it always has done, but better. For example, it’s about exploiting opportunities to fundamentally change workflows instead of simply improving their execution.
T: Transformative. An enterprise architect excels both at driving the short-term steps to achieve quick wins for improving tactical operations and fitting them into a strategic vision for long-term business transformation.
E: Experienced. An enterprise architect needs to have experience at multiple levels. There’s the technical aspect of experience, of course, with skills honed in application development and maintenance, business requirements engineering, and infrastructure planning and support. But also the architect needs to be experienced in the art of politicking — negotiation, compromise, persuasion and consensus-building all come into play.
C: Conflict Confronter. To extend that thought about politics, the enterprise architect is aware that others in the organization are going to be invested in exploring other technologies or other ways of doing things from what the architectural direction is. And he or she knows one can’t be timid in dealing with that. Nice, yes; timid, no.
T: Techno-freethinker. As discussed in our recent article, Enterprise Architecture: Strategize Before You Modernize, the enterprise architect has to come to the table with no preconceived notions of or allegiances to specific technologies or technology providers. You can’t lead — as you must — if your mindset is narrow, rather than open to all options.
Robustness is probably one of the most important priciples in software development. Even more important than Security or Reliability.
The reason is simple. If the software is not robust then it can not be secure nor reliable. Robustness indicates how well the system's other features perform their function and continue to perform their function.
Robustness is a principle and not something you do, if you copy what someone else does to create robust code, you misssed the plot.
Below are some articles on robustness, learn from their thinking process and not from their lists of things they do to improve robustness.
Alberto Gutierrez has a good set of 10 characteristics to learn from.
Matt Bishop's robust programming article.
You may draw a robustness diagram to see all the potential fragile points in your system.
Read more on how robustness is often overlooked or wrongly called "quality".
iMatix tells how they build reliable/robust systems.
Based on the concept, Organization of the artist devised by architect Frank Gehry. The organization of the artist places the architect/artist in control of the design throughout construction and deliberately eliminates the influence of politicians and business people on design. Many IT projects go over budget or fail due to the architect not being in a position to truly run the project. The architect must be mature enough to know the limit of his technology and development teams, he must also know how to get the true needs from the customer and not be swayed by the loud talkers and political players in the customer's ranks.
DataStax’ Brisk is an enhanced open-source Apache Hadoop and Hive distribution that utilizes Apache Cassandra for many of its core services. Brisk provides integrated Hadoop MapReduce, Hive and job and task tracking capabilities, while providing an HDFS-compatible storage layer powered by the Cassandra DB.
DataStax Brisk Apache Cassandra Hadoop
A key benefit of DataStax’ Brisk is the tight feedback loop it allows between real-time applications and the real time analytics that follow. Traditionally, users would be forced to move data between systems via complex ETL processes, or perform both functions on the same system with the risk of one impacting the other.
Rackspace casandra by example:
The Kaizen way is to plan for change. In software development
this can be a bit of a problem because changing software is usually
exponentially more expensive than it was to write in the first place. To make software development lean, one must
counteract this exponential change curve. This is accomplished by using
refactoring, automated testing and continuous integration in order of priority. Once this is in place, change and quality becomes cheap.
From my experience I cannot remember any projects where a heavy up front design has produced a working
project, I can however remember many projects where the principles of refactoring
has saved a failing project. The most successfull projects used refactoring as a way of coding, from the start new features are refactored into existence.
For more information read Martin Fowler's excelent article on the same topic: