IT Architect Training is needed to get your IT organization in the best shape ever. This is the original Architect Boot Camp and started in 2002. These classes are not readily offered at universities, nor at many technical training colleges. Architect training is required because to Read the rest…
Happy Holiday Weekend to my Canadian Friends, Some of you luck ones may have fled your cubes, offices or project rooms – and for those of you left, you might be in for a little reading. If you have been considering the Canadian training Read the rest…
Recently I was asked that if a person was already acting in the role of a software integrator, did they really need to learn how to be an Architect. The answer was a little bit complicated, but it was an emphatic “yes!” While the basis or core skills of a great IT architect does come from solid software integration knowledge and practice, the basic practices, approaches and thought processes as well as ways of thinking in the correct context is what is taught during an IT Architecture workshop. Various approaches and ways of thinking allows an IT Architect to get a new perspective of the various contexts they must review before choosing a solution or constructing an architecture. There are various thoughts on how one becomes an IT Architect, and granted there are so many ways to get here, the result is the same. In order to become good or even excellent, the Architect takes on a different mind set. There are various perspectives that are reviewed, and as well, various options with respect to ways about thinking about the issue, problem or opportunity are reviewed. The architect considers more than fitting two pieces of software together, and the approach learned in a workshop will take them through the business objectives and IT Enterprise objectives, through to the various decision making techniques and options for formulating a solution. Typically the instructions given to an integrator are taken after an architect has determined the best approach and seen best fit for the components that are selected. During these exercises, the architect takes on a different approach with respect to requirements analysis, solution review, as well as some softer skills to deal with the political and communication parts of the equation. Often integrators are given something very specific to be done, as well as a roadmap for doing so. The architect takes part or creates that roadmap, and many more variables are considered than may be actually visible to the integrator. Finally – there are various approaches that an architect learns to getting from A to B. They learn to view a solution from a multitude of angles, and those which will enable them to see their way to the minimal path of risk. In part, the approaches are part of the culture of the organization for which they must have an appreciation for, as well as a component of the overal IT & Business Strategies. Hopefully that sheds a bit of light on the benefits of learning to become an IT Architect, rather than skipping these important steps. For more information on training, see our site. Happy Architecting.
First of all – reminder that the deadlines for early bird pricing on the Architect Boot Camp workshops in October are creeping up on us. Get your registration completed and reserve your spot at Early Bird Rates! There are limited seats, and all we need is your registration, and you’ve got your spot. We’ll send you confirmation and invoices. I’ve been answering a few questions in email lately, so I thought I’d add the questions in this blog: Question: Do you see a big benefit from the Solution Architect Workshop (SAB)? What’s the difference between it and the Information Architect Boot Camp Workshop (IAB)? Answer: The Read the rest…
Lately, I’ve been working on the Architect Boot Camp info site and trying to lay out some really basic architecture information and some more advanced stuff. It dawned on me that there might be some who don’t understand the difference between system requirements and architectural requirements. If this is news to you – stick with me. If not, I won’t waste your time – catch you later.
Architecture requirements are typically those you collect during the initial scoping and context setting sessions at the beginning of a project while you are collecting high level system requirements. You need to determine the business objectives for the system, and for the architecture specifically.
It is so important to ensure that the architecture is aligned with the business drivers and objectives for the project. The architect keeps his or her eye on knowing where VALUE WILL BE ACHIEVED. What are the stakeholder goals? Main criteria for success?.
Setting system context helps to measure scope and set the appropriate boundaries. The architect needs to understand what the system interface will be, and what factors will characterize the architecture. Getting a list of top-level and high-priority goals will assist in setting this scope. This list can be further expanded when moving towards the elaboration phase of the project, and further gather the functional requirements.
The infrastructure must be designed to support the services and functionality that users require. It must deliver the appropriate levels of performance, security, usability and flexibility. All are factors that must be considered at the very beginning during the structure design and concept building of the solution architecture.
If the product is being purchased, the solution or system architects must review the requirements in order to determine their relevance and completeness. Specifically – those relating to non-functional requirements – specifically in the areas of performance, volume, methods of doing transactions or using the system, whom will use the system, how they will use it, etc. require review by the architects.
The architect must also ensure that these architectural requirements align with the Read the rest…