Monday, November 06, 2006
Cooks in the Kitchen
Does it ever seem that as an Enterprise Architect, we have many dragons to slay? Our organizations confuse the Chief Architect with chief technology problem solver, and it isn't their fault. Often the current technology hot spot of the day is something that lives in the EA realm, and we are the captain of the ship.
We've had many metaphors - the Builder, the Architect of a house, the City Planner, or perhaps the Pilot of an airplane or ship (thanks Mr. Zachman!). Here is mine:
An organization, when embarking on an EA program, needs a cook. They need to mix some things up to create a tantalizing dish. There is not often one recipe, but several that might suit the ingredients you have at hand. At some point, depending on the size of the organization, you may find that there are too many cooks in the kitchen, and a chef de maison, or Head Chef is required. The chef will prepare the menu, and ensure that the restaurant has the ingredients at hand.
What the cooks do to add flavor and seasoning may be their choice, or it may be strictly regulated. The McDonalds restaurant does much to ensure that their food tastes the same each and every time. Some restaurants to do - these are not chains, but individual "spots" for a bite out.
Sometimes, there are too many cooks in the kitchen. As of late, I've seen several folks try their hand at mixing and matching SDLC's. The chief architect may or not get involved from a standards perspective, or from a governance and compliance issue with respect to artifacts. There is no "right" SDLC. The facts are simple - too many cooks will ruin the soup - too many flavors will confuse the issue.
One recipe may be selected for the best "dish of the house". There is room to decide whether the head chef is creating the meal depending on the appetite. If there is appetite for chateau briande, so be it. The SDLC will be complex with many options. If there is only appetite for deli or fast food, or perhaps even the corner restaurant that sells burgers and fries, the SDLC must be simple with few key artifacts and simple methods.
Chefs - the choice is yours. Remember, if there are too many cooks in the kitchen, there will be a fire!
Happy Architecting.
We've had many metaphors - the Builder, the Architect of a house, the City Planner, or perhaps the Pilot of an airplane or ship (thanks Mr. Zachman!). Here is mine:
An organization, when embarking on an EA program, needs a cook. They need to mix some things up to create a tantalizing dish. There is not often one recipe, but several that might suit the ingredients you have at hand. At some point, depending on the size of the organization, you may find that there are too many cooks in the kitchen, and a chef de maison, or Head Chef is required. The chef will prepare the menu, and ensure that the restaurant has the ingredients at hand.
What the cooks do to add flavor and seasoning may be their choice, or it may be strictly regulated. The McDonalds restaurant does much to ensure that their food tastes the same each and every time. Some restaurants to do - these are not chains, but individual "spots" for a bite out.
Sometimes, there are too many cooks in the kitchen. As of late, I've seen several folks try their hand at mixing and matching SDLC's. The chief architect may or not get involved from a standards perspective, or from a governance and compliance issue with respect to artifacts. There is no "right" SDLC. The facts are simple - too many cooks will ruin the soup - too many flavors will confuse the issue.
One recipe may be selected for the best "dish of the house". There is room to decide whether the head chef is creating the meal depending on the appetite. If there is appetite for chateau briande, so be it. The SDLC will be complex with many options. If there is only appetite for deli or fast food, or perhaps even the corner restaurant that sells burgers and fries, the SDLC must be simple with few key artifacts and simple methods.
Chefs - the choice is yours. Remember, if there are too many cooks in the kitchen, there will be a fire!
Happy Architecting.
Monday, October 02, 2006
Governance - Abusing the Buzz Word
Well - it's been far too long since I wrote - but I am committed to writing more. I've just been exposed to "governance Overload". What is it you say?
Well - after a weekend in Boston and time with the ultimate of buzz word abusers (this generic professional group shall remain nameless), I'm sick of "get it done", "dropping the ball", etc. etc.
Instead - I come home to a day on my new gig and abuse of the word governance. This blog has turned into a bit of a rant against the abusers of IT architecture and now it's time to spout off against those who can't find their way into a wikopedia entry.
Architecture Governance is different that IT Governance. IT Governance is NOT, and I repeat NOT project prioritization. It might include it, but it is not it. IT Governance includes the process around IT decision making, adhering to standards, patterns and process guidelines. Architecture Governance is the process around governing adhering to Architecture frameworks, guidelines, principles and standards and the methods to make your way around them.
Why does this matter? Confusion about terms such as governance is rampant and since people like to exchange the word "architecture" for the term "diagram", it deserves more references here. Governance is about the process of systematically and orderly controlling the process around decisions. In this case architecture or IT governance. In my case, Architecture governance allows those who wish to sway from the norm to get a say and have a chance at doing something that is right, but isn't necessarily status quo.
Today I sat through a meeting requiring an architectural decision. For a change, I am in a position of both authority and influence and got to be the governing panel. I listened to those who wanted to argue their case for option B when option A was status quo. After all was said and done I couldn't choose either. Both were silly and didn't make security, architecture, nor financial sense. It was option C that won out. See - what a great example of how architecture reviews make sense and are worth the effort. No one came expecting option C to be chosen even though they were afraid to choose it.
Option A was status quo and everyone geared up for option B. By bringing it to my attention, raising it to the top of my radar screen, option C was up for consideration and it won. See - there is a point. There is democratic decision and discussion. Architecture review boards, their process and methods are worth the time and efforts attributed to them.
that's my thoughts for tonight - hopefully I'll be able to share more another day - this was fun!
Sharon
Well - after a weekend in Boston and time with the ultimate of buzz word abusers (this generic professional group shall remain nameless), I'm sick of "get it done", "dropping the ball", etc. etc.
Instead - I come home to a day on my new gig and abuse of the word governance. This blog has turned into a bit of a rant against the abusers of IT architecture and now it's time to spout off against those who can't find their way into a wikopedia entry.
Architecture Governance is different that IT Governance. IT Governance is NOT, and I repeat NOT project prioritization. It might include it, but it is not it. IT Governance includes the process around IT decision making, adhering to standards, patterns and process guidelines. Architecture Governance is the process around governing adhering to Architecture frameworks, guidelines, principles and standards and the methods to make your way around them.
Why does this matter? Confusion about terms such as governance is rampant and since people like to exchange the word "architecture" for the term "diagram", it deserves more references here. Governance is about the process of systematically and orderly controlling the process around decisions. In this case architecture or IT governance. In my case, Architecture governance allows those who wish to sway from the norm to get a say and have a chance at doing something that is right, but isn't necessarily status quo.
Today I sat through a meeting requiring an architectural decision. For a change, I am in a position of both authority and influence and got to be the governing panel. I listened to those who wanted to argue their case for option B when option A was status quo. After all was said and done I couldn't choose either. Both were silly and didn't make security, architecture, nor financial sense. It was option C that won out. See - what a great example of how architecture reviews make sense and are worth the effort. No one came expecting option C to be chosen even though they were afraid to choose it.
Option A was status quo and everyone geared up for option B. By bringing it to my attention, raising it to the top of my radar screen, option C was up for consideration and it won. See - there is a point. There is democratic decision and discussion. Architecture review boards, their process and methods are worth the time and efforts attributed to them.
that's my thoughts for tonight - hopefully I'll be able to share more another day - this was fun!
Sharon
Thursday, August 10, 2006
Business In the Driver's Seat
“By 2008, 40% of enterprise architects will have primary expertise in business strategy or process engineering” 2004 Meta Group, Inc.
They get it. Businesses appreciate, accept and now accentuate the role of the architect in their organizations. It took some time, but they get it now. I might generalize and say that most medium size businesses have some sort of architecture function in their midst. I’d go further an say every large business now believes that architecture is the brass ring as far as IT success is concerned.
The business drives the business, and now we, as IT practitioners get it. We are finally focusing on things like Project Management, Business Analysis, Business Process Reengineering, Portfolio Management and aaahhh, yes. Enterprise Architecture. EA starts with the business strategy, and the great architect will become verse in business strategy. Our business strategy.
For more details on these thoughts, check out my information site and an article entitled "Business In the Driver's Seat"
They get it. Businesses appreciate, accept and now accentuate the role of the architect in their organizations. It took some time, but they get it now. I might generalize and say that most medium size businesses have some sort of architecture function in their midst. I’d go further an say every large business now believes that architecture is the brass ring as far as IT success is concerned.
The business drives the business, and now we, as IT practitioners get it. We are finally focusing on things like Project Management, Business Analysis, Business Process Reengineering, Portfolio Management and aaahhh, yes. Enterprise Architecture. EA starts with the business strategy, and the great architect will become verse in business strategy. Our business strategy.
For more details on these thoughts, check out my information site and an article entitled "Business In the Driver's Seat"
The Architect and the Merger & Acquisition
Mergers & acquisitions – Calling All Architect’s – We’ve Got a Merger & Acquisition
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
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
Tuesday, May 30, 2006
Information Architecture Gets Super-Sized
Hello,
Long time no type -I've been really busy writing content for my latest courses and this came up during research. Each month I play a game - search Google for the keywords "Information Architecture" and see how many bogus links you find before you get to the real stuff. Today I only got to this Maskery Tom Foolery before I had to stop and write something.
The sad thing is that I don't know the answer to my question - how many pages does it take before one searching for information architecture can get to the real stuff? Last month, it took 19 pages of Google links before I found something that even resembled information architecture.
Why do I call the fluff not so real? There are so many folks eager to super-size IT, IT Roles and borrow or steal the work architecture to make their products look a little more saleable, and specifically those working in pure web site development and content management are the villains here.
I've said it before, but I'll say it again - Information Architecture INCLUDES content management and web page/site structure design. It is not Information Architecture. IA is all that surrounds the information domain within the system or enterprise architecture. It includes servers and software that house the databases, their structures and operational systems. It includes the many types of data and database models, as well as the repositories, scripts and dictionaries used to describe the data and content stored. It CAN include content management software and the infrastructure required to run it.
This page I've referred to above states the following: Below is a schematic of an information architecture
NO - this is not a schematic of an information architecture. It is purely a website navigational map, or as VISIO terms it, a WEB SITE MAP. It is not the architecture - do you see any diagrammatical objects that depict where the information is to be stored, how it is to be stored, and in which technical manner? Do you see any models of the data, or conceptual intent? Do you see any relationships between the data.
Sadly enough, there are hundreds, if not thousands, of companies slogging this marketing type with their product. Super-Size is a McDonalds term, and I'm using it here to refer to the act of making something seem large just to sell more, without much more than added calories. If you want to see more of what this stuff is really made of, see my Information Architecture page.
Long time no type -I've been really busy writing content for my latest courses and this came up during research. Each month I play a game - search Google for the keywords "Information Architecture" and see how many bogus links you find before you get to the real stuff. Today I only got to this Maskery Tom Foolery before I had to stop and write something.
The sad thing is that I don't know the answer to my question - how many pages does it take before one searching for information architecture can get to the real stuff? Last month, it took 19 pages of Google links before I found something that even resembled information architecture.
Why do I call the fluff not so real? There are so many folks eager to super-size IT, IT Roles and borrow or steal the work architecture to make their products look a little more saleable, and specifically those working in pure web site development and content management are the villains here.
I've said it before, but I'll say it again - Information Architecture INCLUDES content management and web page/site structure design. It is not Information Architecture. IA is all that surrounds the information domain within the system or enterprise architecture. It includes servers and software that house the databases, their structures and operational systems. It includes the many types of data and database models, as well as the repositories, scripts and dictionaries used to describe the data and content stored. It CAN include content management software and the infrastructure required to run it.
This page I've referred to above states the following: Below is a schematic of an information architecture
NO - this is not a schematic of an information architecture. It is purely a website navigational map, or as VISIO terms it, a WEB SITE MAP. It is not the architecture - do you see any diagrammatical objects that depict where the information is to be stored, how it is to be stored, and in which technical manner? Do you see any models of the data, or conceptual intent? Do you see any relationships between the data.
Sadly enough, there are hundreds, if not thousands, of companies slogging this marketing type with their product. Super-Size is a McDonalds term, and I'm using it here to refer to the act of making something seem large just to sell more, without much more than added calories. If you want to see more of what this stuff is really made of, see my Information Architecture page.
Thursday, May 04, 2006
Connect the Dots - EA and Portfolio Management
Ok - so maybe you haven't heard the buzz about the marriage between EA and Portfolio Management. It's been going on long enough to get the seven year itch already - so why should I go on about that today?
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
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
Monday, April 03, 2006
WHAT IS AN ARCHITECTURE FRAMEWORK?
One of the most ambiguous words in the initial understanding of Information Architecture is that of the Framework. The Framework is a generic categorization method for architecture design artifacts. Any good categorization method achieves these EA goals:
1. Simplify information for understanding and communication
2. Clearly focus on independent components for analytical purposes
3. Provide and maintain a disciplined method of depicting relationshipsbetween the domains.
A Framework is a set of approaches, components, configurations,models, services, standards and principles that can guide you in your documentation adventure of a particular view of an architecture.
HOW CAN I BENEFIT BY USING A FRAMEWORK TO GUIDE DESIGN?
While there are many benefits in using a framework to guide your development efforts of an architecture, there are two that are moreelementary and prevalent than others: Guidance and Communication.
The framework is a guidance tool which is used to ensure that each architecture domain is adequately reviewed and documented, and canmost easily be compared in context to the other domains or views. It guides both the method and approach to completing an architecture,and enables all stakeholders to see a consistent and complete picture when reviewing an architecture.
The framework can be used as the primary communication vehicle between architects, the project team, stakeholders and IT technical staff. It can be used to show what you've planned, and how you will achieve flexibility in the future.
Other benefits that you may expect from using a framework, is the provision of a generic space and structure for a very complex and varying problem. It can include a starter set of principles, issues and concerns. It can provide guidance on which sets of diagrams and models to include.
Think of it as a "placeholders" map to what would make a complete architecture. It is also known as a set of views of an organization and its Business and IT Resources and assets.
WHAT FRAMEWORK CHOICES ARE AVAILABLE?
There are numerous frameworks available to be used, but they are primarily categorized by domain. They are typically designed for government, or non-government (private organization). Some are strategically oriented and some are focused on organizing the evolution of the architecture.
An organization can choose to adopt an existing architecture framework or to build a custom framework. In either case, it is rarely necessary to start from scratch, and the primary focus should be on the stakeholders and the domains you wish to capture. Try to keep in mind that the primary goal here, is 'Communicate that architecture!'
If you choose to adopt an architecture, consider visualizing what kind ofdata and models you will use to populate it. Ask yourself 'what is important to my organization?', and 'how have we organized our departments and business in the past?' Many frameworks are used for a particular type of community, so try to pick the one that is most similar to yours.
Enquire with peer organizations as to which type of framework they have used. There is value in understanding and using more than one, so pick the one that is the closest, and adapt it by selecting one or more components you would need to close the gaps between the one you select and what you need for your organization.
If you choose to build one, please consider finding one or two that have components of what you need and take pieces to build your own. We really don't need to reinvent the wheel. I prefer the 'a la carte' method myself, and have actually trimmed one of the most simple and straight-forward frameworks available, then customized the look, feel and tools as well as the processes for it. Customize it to suit your culture and technical vocabularies for the ultimate in success!
WHAT FOLLOWS YOUR FRAMEWORK CHOICE?
Today's newsletter won't attempt to describe the Enterprise ArchitectureProcess, nor the strategy to complete it. What I can do is give you a few hints about your next move after choice. I have spent a great deal of time and effort studying and customizing decision making techniquesfor my consulting engagements, and one of my secret weapons is the'litmus test'.
After a framework has been selected, evaluate it's use within your business environment. Review the goals and objectives in using such a framework, and see if what you picked will work. After treading througha few examples, list the lessons you may have learned and refine whatyou've selected.
So there you have it - my quick thoughts on Frameworks. I have many more, but these are the basics that I might write about without much effort.
1. Simplify information for understanding and communication
2. Clearly focus on independent components for analytical purposes
3. Provide and maintain a disciplined method of depicting relationshipsbetween the domains.
A Framework is a set of approaches, components, configurations,models, services, standards and principles that can guide you in your documentation adventure of a particular view of an architecture.
HOW CAN I BENEFIT BY USING A FRAMEWORK TO GUIDE DESIGN?
While there are many benefits in using a framework to guide your development efforts of an architecture, there are two that are moreelementary and prevalent than others: Guidance and Communication.
The framework is a guidance tool which is used to ensure that each architecture domain is adequately reviewed and documented, and canmost easily be compared in context to the other domains or views. It guides both the method and approach to completing an architecture,and enables all stakeholders to see a consistent and complete picture when reviewing an architecture.
The framework can be used as the primary communication vehicle between architects, the project team, stakeholders and IT technical staff. It can be used to show what you've planned, and how you will achieve flexibility in the future.
Other benefits that you may expect from using a framework, is the provision of a generic space and structure for a very complex and varying problem. It can include a starter set of principles, issues and concerns. It can provide guidance on which sets of diagrams and models to include.
Think of it as a "placeholders" map to what would make a complete architecture. It is also known as a set of views of an organization and its Business and IT Resources and assets.
WHAT FRAMEWORK CHOICES ARE AVAILABLE?
There are numerous frameworks available to be used, but they are primarily categorized by domain. They are typically designed for government, or non-government (private organization). Some are strategically oriented and some are focused on organizing the evolution of the architecture.
An organization can choose to adopt an existing architecture framework or to build a custom framework. In either case, it is rarely necessary to start from scratch, and the primary focus should be on the stakeholders and the domains you wish to capture. Try to keep in mind that the primary goal here, is 'Communicate that architecture!'
If you choose to adopt an architecture, consider visualizing what kind ofdata and models you will use to populate it. Ask yourself 'what is important to my organization?', and 'how have we organized our departments and business in the past?' Many frameworks are used for a particular type of community, so try to pick the one that is most similar to yours.
Enquire with peer organizations as to which type of framework they have used. There is value in understanding and using more than one, so pick the one that is the closest, and adapt it by selecting one or more components you would need to close the gaps between the one you select and what you need for your organization.
If you choose to build one, please consider finding one or two that have components of what you need and take pieces to build your own. We really don't need to reinvent the wheel. I prefer the 'a la carte' method myself, and have actually trimmed one of the most simple and straight-forward frameworks available, then customized the look, feel and tools as well as the processes for it. Customize it to suit your culture and technical vocabularies for the ultimate in success!
WHAT FOLLOWS YOUR FRAMEWORK CHOICE?
Today's newsletter won't attempt to describe the Enterprise ArchitectureProcess, nor the strategy to complete it. What I can do is give you a few hints about your next move after choice. I have spent a great deal of time and effort studying and customizing decision making techniquesfor my consulting engagements, and one of my secret weapons is the'litmus test'.
After a framework has been selected, evaluate it's use within your business environment. Review the goals and objectives in using such a framework, and see if what you picked will work. After treading througha few examples, list the lessons you may have learned and refine whatyou've selected.
So there you have it - my quick thoughts on Frameworks. I have many more, but these are the basics that I might write about without much effort.
Tuesday, March 21, 2006
The Crystal Ball
Do You Have a Crystal Ball: 3 Future State Architecture Keys to Make them Think So!
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.
Sharon
Tuesday, February 21, 2006
The IT Profession - Are We Ethical?
Hello - long time no chat.
I've been away building and authoring courses, so writing has gone into something other than frivolous blurbs. Just came back from an evening with a speaker on ethics - it was supposed to have something to do with Ethics in IT and although that's not what it was about, I was able to draw a few lines and relationships to IT from what the speaker had to say.
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.
I've been away building and authoring courses, so writing has gone into something other than frivolous blurbs. Just came back from an evening with a speaker on ethics - it was supposed to have something to do with Ethics in IT and although that's not what it was about, I was able to draw a few lines and relationships to IT from what the speaker had to say.
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.
Subscribe to:
Posts (Atom)
