Title

Current Role

Interests

Current Skill

• Developer

• Analyst

• Technologist,

• PM

• Project Interest; Terminology;

• Pondering a field in IT Architecture

• IT analysis, design

• Construction

• project management

• staff management

• Senior Business or IT Leaders

• CIO, CTO, Business and IT Strategists

• PMO and Project Managers

• Executive Level Understanding of process, approach and benefits of architecture.

• Strategic planning, IT portfolio management;

• IT & Enterprise Architecture development, management

• Management;

• IT Portfolio;

• Strategic Planning;

• Budget Analysis;

• Project management

• Business

• Architecture Team Member,

• IT Architects

• Senior System Designer

• Guide and Define the current and future state of an organization

• Transition paths, standards & principles

• Lead or participate on EA Team

• IT Architect, Strategist, Leadership.

• Excel in concepts, planning, strategic.

• Sees the big picture;

• Extremely strong in abstracting the situations, processes.

• New or novice architects (various domains & types),

• senior developers,

• systems analysts & specialists

• Construct basic architecture artifacts, documentation

• Basic Funamentals and understanding of roles, skills, methods and process of IT Architect (various domains, EA)

• System Design & Analysis.

• Project, Solution or high level design responsibilities

System Architect

• Application or software architects;

• Senior systems analysts, senior developers & system designers;

• Solution architects;

• Functional process analysts

• Conversion of the requirements into an architecture and design that will become the blueprint for the solution being created

• Software design, System analysts, Solution scoping;

• Define the interaction between components;

• prototype;

• Background in software development methodologies

• Business architects,

• business analysts,

• systems analysts,

• solution architects

• Create business architecture artifacts;

• business transformation;

• Document Business Strategies, Capabilities,

• Processes from the architecture perspective

• Business and/or systems

• Participant in strategic planning,

• Business process redesign & requirement gathering;

• Models workflow & process

• Technical architects,

• technical specialists,

• infrastructure specialists,

• security architects

• Build a technology blueprint;

• select and analyze infrastructure components;

• Hardware configuration, software and solution technology components

• Understanding of the technical aspects of application, solutions and infrastructure.

• Technology specialties in some special areas such as hardware, operating systems, desktops, network, security, facilities, system software, operational processes.

• Design technology components for prescribed IT solutions.

As enterprise architects, we attempt to capture business strategy and put some alignment to our IT Strategy, and formulate an IT Current State and IT Target State architecture. The IT plan is the people, process and technology initiatives that we plan for the year, and potentially two or three threes out to move towards IT future State.

We have to have an understanding of the business strategies, priorities and external business environments to drive the overall strategic IT objectives. Analysis of the business changes and priroities drive the characteristics of the IT products and services, IT governance and the required IT capabilities.

IT Architecture is how we plan, and the basis for the efforts that we employ during the year to move closer to our goals. Definition of the technology, application and data architectures enable the IT strategy. Each must align with the business architecture, or functions and processes that we perform as an organization to sell or provide service to our customers. Effective IT planning is derived from tactically focusing on closing the gap between current state and target state.

The technology landscape is where my thoughts lie today. IT strategy is a business driven lifecycle, and it’s difficult to jump directly to the technology landscape when reviewing the linkage and relationships from the business. IT planning is an on-going event constantly refreshed to meet the shifting future state. It makes sense after we determine which data we need, and what solutions we will use to provide or manipulate that data. It is only after this point that we can determine which technologies we will use to deliver these solutions.

What if we consider the big jar and the stone philosophy? We have a large jar, and we fill it first with big stones, then smaller stones, then pebbles, sand and water to fill it. Our large stones in the area of technology architecture shouldn’t change often. Meaning – if we have an IBM mainframe solution, using a Nortel or Cisco network, and HPUX server farm, we’ve determined how we general want to continue to operate. Although we may have quite a mixture, we should generally know what our general direction is on the larger technology components each year – or which direction we intend to move as big changes are made.

These technologies will rarely have wholesale changes. Our technology landscape will generally stay the same, yet each year we must consider which larger and smaller scale changes should be made. There are none that should be made purely for sake of change itself, nor for the sake of “cool and new” technologies, unless innovation is our core business product.

In saying this, we as technology architects have the best chance of putting together our target state with the most certainty. Each solution and information requirement will cause us to change direction somewhat. We as technology architects should attempt to map how our technology components match to the business drivers in our strategic plans, but if this isn’t possible for us, or resides with our enterprise architects, it behooves us to have a very good understanding of the categories of technology components that we carry, the ones that should be slated for replacement, and those that should be enhanced.

Technology Landscape is most likely the most straight forward target state of the three domains. The minor stuff like lists of specific point software, appliances, etc. can be added as our needs are nailed down.

If technology architecture interests you, watch our seminars page at www.architectbootcamp.com for more information.

What are your IT Project Priorities – do you have one of those “Yours, Mine & Ours” situations???

What I mean is that when a business decides to buy another company, or merge with one, often there are multiple perspectives to project priorities. If one business arm decides they need a bigger sales force, and another wants to gain proficiencies in a manufacturing process, there may be conflicts. Add the fact that the IT area wants to streamline, yet add or upgrade technology infrastructure, we’re cooking up a recipe for missed expectations.

The IT Architect needs to understand what the end goals are by the business when creating the architecture. If you want to read more on ensuring you understand the right messages and goals, why don’t you check out my information site – Mergers & Acquisitions and the Information Architect is an article that addresses this topic.

It’s a sample exerpt from our eZine “The Architect Abstract”. Head to the site to sign up to get a copy every week, or view the sample articles to whet your appetite.

Happy Architecting!
Sharon

My head hurts – I’ve been knee deep in the weeds building courseware for about three months and I’ve come up for air. It’s probably the first thing I thought of because I was digging up some articles for a participant in a workshop that was in need of more info on the topic. Or maybe it was because I was drawing diagrams all night and when I was done I couldn’t remember if the diagram was going into an article for a Project Management piece on Portfolio Management or an Enterprise Architecture.

To make a long story short – they are the same Portfolio Management. Different constituencies might care for different reasons, but at the end of the day, the same portfolio should be planned. Granted – if the Enterprise Architect gets their way – there will be the project completed that gives him or her the best new models to add to their collection – isn’t that what everyone thinks we do? Or is it picking the standards that everyone has to follow????

Actually – it will fill a gap from the charts on the analysis task of the most recent EA program review. And – it will match up to the latest and greatest business initiatives sadly lacking archtitecture. What difference does it make? The EA’s and PM’s need to work together, and other than a few squabbles about scope – aren’t they fighting the same battles? To get sorely needed projects done with precious few budget dollars?

Another thought on the subject – the project manager and the program or portfolio manager are fighting different battles. The project manager wants to get the project done as directed, with as little risk and variance on budget as possible, with the best use of resources as possible.

The EA wants to get the right things done, and usually budget is the last thing on their list, other than the fact that they don’t want their EA program shut down. So – we’ll all have to get along here. We want to do the right things, ones in the best proportion to keeping the business running, getting the optimal amount of growth in the organization, and transforming that organization to meet strategic needs of the executives and planners.

At the final outcome, both parties will be happy if they solved a business requirement, met an organizational objective and ok, created a few models along the way. Is that so bad?

Happy Architecting,
Sharon

Documenting the current state architecture is a must to any enterprise or system architecture report, and even though we understand this, it’s the future state that everyone is anxious to see and share. Let’s face it – they are also waiting to critique it. There are components of a future architecture that make or break its impending success – or failure. It seems that there are three surefire keys that you can include to ensure success!

Let’s suppose you are responsible for the System Architecture or Solution Architecture for a new custom application in your enterprise. What mandatory items should your checklist include when documenting the future architecture?

1) Strategic Direction

Opportunity creation can be achieved by analyzing relationships between Strategic Drivers and Business Architecture Components. Those who need to buy into your future state architecture need to be able to visualize the opportunities, and taste those benefits! The business architecture should include these items to articulate strategic direction:

• List and adequately describe the Strategic Drivers behind the architecture. If there are many to be listed, separate them into “Primary” and “Secondary” or some other tiered scheme.
• What new opportunities will be addressed by the new system?
• What potential future opportunities are on the horizon can be accommodated by the future state architecture (read flexibility!)

2) Justification should be the key focus in the System Architecture (Application & Information). You will gather information for justification of system enhancements while analyzing the relationships between the Strategic Drivers and the System Architectures

• Define what kinds of application systems will be relevant to the enterprise (based on strategic drivers)
• Describe the application as logical groups of capabilities that manage the information (capabilities that match to the strategic drivers)
• Describe the methods that support the business functions described in the Business Architecture (Linkage)

Include these items in terms of both the Application and Information, and you will have justified the new system.

3) Automation Efficiency should be the key focus in the Technology Architecture. Benefits can be collected when analyzing relationships between Strategic Drivers and Technology Architecture

• Describe future standards and technology principles required to support the new system (based on the strategic drivers)
• Describe the technology platform required for the new system
• Describe the anticipated distribution of data and applications

If you are able to create a visual presentation for your audience, include these three main points on your agenda – tell them that you will prove that your future state architecture provides alignment with strategic direction, added capabilities to enable business drivers, as well as automation efficiency using technology, and I’m sure that you will definitely have an interested audience!

For up to date information on IT Architecture, visit www.architectbootcamp.com.

Happy Architecting

Sharon

A few thoughts that came to me through this – there was someone who asked how it was related to Risk Management. It came from a security professional who was also a Security Consulting firm owner. In a way, it seems that about half of the questions posed in one of these sessions are self-serving, and this seemed to be one of them. The speaker gracefully told yet another anecdote – the speaker seemed to have nothing but, but we heard about the Pinto story. The company weighed their options, and chose the least expensive, without looking at the risk or harm to the ones that would be blown up.

The speaker also told anecdotes about butterfly ballots and the loss of trust and believe in politicians. I’m not sure this has changed over time, but rather has just become more exposed because of IT and the world of information. Scandals are instantly publicized and we can find out both the truth and rumours almost moments after they happen.

The speaker specialized in Biometrics & Ethics and stated that they didn’t trust the medical system or doctors. This came from the whole whistleblower issues and the lack of benefits to those who do expose those who stretch, bend and manipulate the better good of society for medical profits. Doctors and hospitals take money for research, funding and sponsorship in exchange for the promotion of a pharmaceuticals drugs. Researchers are encouraged to hide data that might be detrimental to the unveiling of a prospective lucrative drug.

How does any of this relate to IT? The speaker did mention IT a couple of brief times – both times resonating something within me. His first comment was that we are now able to get a lot of data cheap, which is causing trouble in this world. Examples were getting enough data to steal people’s credit cards, get enough information to impersonate, and also to spread viruses and cause billions of dollars worth of damage. He alluded to the fact that we are able to get information fast which might be helpful. No anecdotes – this might have been about fear and his anecdotes about the bad were better than the good.

How about being able to send email to those we like and love that have moved away, or sending notes back home when we are forced to be away. How about getting information from legal sites on companies that we are about to do business with and expose the frauds they are before they happen? How about researching tools and items for purchase in a preliminary way, bettering our decision making processes, or arming ourselves with background information so that we might ask better questions in order to get better results. Our infrastructure designs have become so complicated and we have so many choices – we NEED to get information quickly.

The second thought I had during all of this, was that if we are to be ethical, we must balance our need to make a living and a profit in doing the right thing. We as architects must weigh our inherent desire to design the best architecture with one that is good enough for the time and budget allotted. Professionals such as engineers, architects, doctors and accountants take oaths that they may or may not be able to recite a few years past their indoctrination, but most will not sign or do things they know will jeopardize their licenses.

We don’t have licenses, not yet anyways, that we can use as our backstops and reasoning against doing the wrong things. All we have is our pride and reputation. We can use our talent and skill to do the right thing and pick the best architecture or make the best architectural choices that fit our PM’s budget, time and quality requirements. We have to protect our reputations, and sometimes we have to walk away from the project, contract or decisions that we feel are not right, even though we are feeling intense pressure to do otherwise.

Happy Architecting!

The place I spend many minutes were incredibly equipped to deal with the disaster. They have a DRP appropriate for their size and focus. We had PC’s to work on in another facility within 120 minutes. The PC’s were not equipped with the software which most of us needed, but we were able to spend some minutes doing something productive in most cases. Two departments were sent home, as there were only so many PC’s, and only so much spare space.

In contrast, there were vandals who were also disgruntled employees of a large tenant company in the same building in which I spend many minutes. They decided to use the fire hoses on the top floor and play games by filling the stair wells with water to express their discontent. Their employer decided to only pay them for a small portion of the day of pay they lost for that same electrical interruption. With only four weeks before Christmas, and being paid only marginal amounts over minimum wage, can you see the point of aggravation?

Now all companies affected must pay an insurance company to clean up their messes in offices that span the building, and the insurance company gets to collect several premiums because all tenants affected must pay, and the restoration company will pretend that they can do all of the work and make things right. And, next year and for the next five, all of these affected companies will get to pay some rich insurance companies extra premiums for bad experience.

Do I sound facicious here? I definitely am being so, as I have been the victim of water damage once and had to use that same restoration company. Believe me – you don’t ever want to encounter this so go right home and make sure you have the bullet-proof hoses on your washing machines, buy a water beetle and hook it up to your alarm system, and definitely ensure that the little birdies outside aren’t making nests in your bathroom vents so that vents are forced open and pipes may freeze.

Also – I am facicious because I have seen that tenant who employs the vandals exploit their staff, vendors and suppliers. If they would have coughed up the dough to pay a full days’ pay, or had a disaster recovery plan to enable the workers to do something else productive, none of that would have happened.

I continue my attitude as I had dinner with colleagues the day following the incident. We all shared work experiences and customer stories of the places in which we are spending many minutes. I found it humourous, then aggravating that one was spending two years of a client’s money creating a DRP and they still didn’t really get the point. Most companies who embark on DRP’s shouldn’t really call them that. They should call them their “how to get my technology all up and running”. Most have limited budgets and cannot begin to create a plan to recover everything. What about the business?

Why bother? Is everything that important? Is the little system that your company uses to catalogue the books in your IT library, or the research reports employees create when they really should be doing something else important? Yes – these things are great to have, if you actually had a reason for creating them, but is more than a back up really that important.

You knew I’d eventually get back to Architecture – I always do. I eat sleep and breathe the stuff. A great EA can completely replace the need for the kind of DRP these companies think they need. If your business functions are well (and I don’t mean completely) documented, and you know which ones you need to keep the $ rolling through the doors, and what their priorities are, why spend the equivalent of three or four peoples salaries in a year paying a consultant or two to write you a plan to recover everything you have as fast as you can? Believe me, some stuff can wait, and a backup of the data is likely sufficient.

If you need to get help on a DRP plan, I suggest you find someone who understands the concept well. If you want to completely document your technical architecture, good for you, but tying it to the recovery plan will only delay the process. The two should be separate endeavours and it should be pretty easy to figure out which one comes first. Key word is should.

There – the satiristical side of me. I promise to behave next time out – this was a tough week to feel productive.

The I.T. Architect is a technologist, a leader, a consultant, a strategist, a politician, a writer and an artist. Yes, I threw that last one in for humor, but I get countless “way to go Picasso” comments, when I’ve helped a client with a modeling conundrum, or even cleaned up after a whiteboard session and converted our thoughts into something readable, tangible and electronic.

As a technologist, the architect must specialize in technology, information or applications if he or she is a domain architect “Data Architect, Information Architect, Technical Architect, Application Architect, Software Architect, etc.” I must understand the pertinent technologies, plus have an in-depth understanding of the entire domain. Learning the key issues around my domain and knowing the Best Practices and key standards, methods, processes and techniques key to being a good practitioner is also necessary.

I consider all the matters at hand, and analyze the tradeoffs. I get to “play” by prototyping and experimenting with technologies, taking various system viewpoints when drawing up models and then testing them later with prototyping tools. I am fortunate enough to keep tabs on the “what’s new” in technology, and follow the trends and create roadmaps for the future. Mapping out where you want to go is always done in a more positive light than where you have been.

As a not such an enjoyable task, the Architect must document and present their findings to incredibly critical groups of people. Everyone has an opinion, and at the end of the day, even with a little bickering and bantering, it’s all a good thing. I’ll take that over dead silence any day. I get to do the investigations, and create the future, so I must be tolerant of changing my work on an ongoing basis to accommodate the opinions of many, while maintaining my initial vision.

Happy Architecting!

This year was a little different. More keynotes, but fewer messages. The last one was fabulous, so all is not lost. John Zachman has finally admitted there is no silver bullet and still maintains that one day we will all wish we’d filled his magic framework. I’m not arguing but there were more that agreed with me this year that feel practicality is a virtue.

The conference offered two panel sessions this year, and not as a keynote. Great touch – heard some great things except for a 30 minute drone about certifying EA’s. There is much passion about this, but hard to get excited after listening to it around the CIPS ISP. Sort of boring and so far from reality. Perhaps we should work on a common vocabulary as I hear more acronyms that you can imagine for what goes on in the Business Architecture. Reminds me of the early nineties when modeling tools first entered the scene and with a flick of a button you could create a new flavour of the day – all of which equated to a logical or process flow diagram.

There was an increase in both the sessions and numbers of folks who attended the “Build” as well as “Run” Sessions. Good for you! This just means that there are the masses attending the Plan, meaning we still don’t have anything done yet.

The most common question I heard all week was “how do we know when we’ve modelle enough?”. Various answers – deserves a blog onto it’s own – but all it means is that we’re progressing.

Well – have to type more tomorrow – 4 bells come early and I will take a break from this little stanza.

Happy Architecting and Happy Friday!
Sharon