Yes, your annual performance review is behind you now and you are probably still basking in the glow of our previous year's accomplishments.
With the new year approaching I want to suggest you make a regular habit of specifically seeking feedback from your manager in your one-on-one meetings. I am not talking about vague generalities, e.g., "How am I doing?", but opening yourself up to being willing to hear detailed, performance review level, feedback.
I recommend you use the Start-Stop-Continue approach. Ask your manager,
1. What should I start doing?
2. What should I stop doing?
3. What should I continue doing?
Simple isn't it? But don't ask if you don't really want to hear the answers. And if you do, keep asking until you start to get the kind of feedback you expect. You may find that your manager to be hesitant at first to "go deep" on your performance. I suggest you give your boss a few days heads up that this area will one of your 1:1 agenda topics.
Now if we can get managers to pop the same three questions to their direct staff from time to time!
Monday, November 13, 2006
Competive Architectural Business Strategies
For the last few years at I've been honking like a goose about the commoditization of hardware and a hardware-centric company's need to build a strong software core competency upon which it can begin to build a whole-platform architectural franchise. The recent announcement of the "platformization" of Intel Corporation was music to my ears. In today's post I describe some of the strategies needed to begin building these architectural franchises.
Unfortunately there are a lot of people involved in strategy activities that do not understand the process. From what I have observed developing business strategy is sort of like teenage sex...
1. It is on everybody's mind all the time
2. Everyone talks about it all the time
3. Everyone thinks everyone else is doing it
4. Almost no one is really doing it
5. The few who are doing it are:
- Doing it poorly,
- Sure it will be better next time,
- Not practicing it safely.
I emphasize the word 'strategy' in this context because the effort is long term and a "bet the business" decision. When I use the word 'strategy' I mean a defined plan of action that will develop a business unit's competitive advantage and compound it.
I think there is a tendency to confuse strategic long range planning processes and the their outputs as strategy-making and strategy, respectively. I would submit that in their present form most of what I have seen more closely resemble mechanized marketing activities as opposed to development of a concrete plan to act and leverage competitive advantages for compounded revenue growth. Could it be that we just might be spending too much time trying to ring the cash register and too little time thinking about the long-term directions we should be taking and the technologies, resources, etc., we are going to need to get there?
I have seen lots of great long-range plans to build way cool technologies, but very few plans that show how the technologies already in place (or to be built) can be leveraged into an architectural franchise. Folks, bad technology and good strategy will always beat good technology and bad strategy. Just look at the success of Microsoft. From a software architectural perspective, the Windows operating system is an abomination. Definitely bad technology, but, oh my, what a wonderful strategy is behind it, no?
To build a platform level architectural franchise, a company is going to have to wage quite a battle in the marketplace. Market position as a hardware supplier will not give a company a significant advantage until it has closed the credibility gaps in those areas outside of the hardware business it chooses to enter. The operating system competition we are witnessing today between Microsoft and the open-source community are really architectural wars. As we are seeing or have seen, the architecture battles a company must choose will consist of one of four options:
1. fight them
2. become a countervailing power in a non-competing space
3. exit the space (alive or dead)
4. compete on implementation
So what should a company be doing to be ready to do compete and to win? To win any architecture competition, a business unit must sign up to a long-term, bet the business strategy and not be short-sighted because of near-term needs for cash flow. The components of such a long-term strategy must include:
1. A commitment to architect the state space and our products- backed by money, time, and talent with executive management backing.
2. Excellence in initial products- this is critical or you become the next Visicalc or Iridium, that is, you become the first to prototype a market for someone else to own (note: being first is not always a winning strategy). And remember, excellence is not defined by the technologist, it is defined by the user.
3. A plan for diffusion, versus retained control, across the market to establish leadership- as the architectural franchise opportunity takes shape contenders will appear offering the chance for alliances, licensing, and early architected products. This is one of the most difficult architectural challenges best met with a selectively open design; near seamless compatibility with supporting point products and commodity components; and wide, but carefully managed licensing.
4. Establishing and maintaining strong allegiances with after market products and users- supported by a broad, complex supporting infrastructure to increase switching costs, e.g., lots of toolkits with significant examples that reduce the customer's time to money.
5. A plan for harvesting and extending the existing architecture (most companies cannibalize themselves too late)- expansion and enhancement of architectural coverage while tightening proprietary control, yet leaving the architecture open and available. This means the architecture must be extensible enough to be extended from the initial niche into a steady stream of architected product lines and not just a series of point products. Static architectures will be devoured by clones!
6. Eventual architectural replacement- as the architecture ages develop new layers atop it to facilitate migration of its users and products to a new architecture, thus giving the new architecture a jump start on a new diffusion cycle. But before you throw the baby out with the bathwater, consider this story.
When Motorola first got into the GSM cellular business, it went out and purchased some protocol stacks thinking this would get them to the market quickly. Next it created its own "exec", a lean operating system kernel. It got both of these strategies backwards. The cellular protocol architecture is so interwoven with an overall system software architecture that to not have complete control over it means you are forever at the mercy of the supplier's own design. In effect, Motorola bought into a bunch of accidental complexities that ultimately led to a discard of this software and development of the complete stacks in house.
The exec design never met performance expectations and did not anticipate the future demands of new services not yet dreamed about. It, too, had to be discarded and replaced with an off the shelf product.
The point here is that the operating system was not the driver of the value add of the company's products. It supplied the usual services, but was something that any number of products on the market could do. There was no need to develop a new one in house. The protocol stacks, however, ubiquitously touched nearly every major software subsystem, yet the development team had no control over this design and had to dilute system strategies to accommodate the third party vendor's design. In effect, the tail was wagging the dog.
Like the item above implies, a company must hold onto the sand that becomes the pearl. All else can be bought on the open market, but we cannot afford to give up on an unfair advantage made possible by having complete control over a system architecture. This yields minimum accidental complexity and maximum chance for establishing an architectural franchise.
7. Intellectual property management- essential at every stage of the life cycle of the architecture and implies careful patent preparation and constant monitoring and enforcement.
Thanks for sticking with me this far. So, to conclude, what is the message here? Selling microprocessors, chipsets, motherboards, etc., is a credible first step, but companies must start planning and acting now for the follow on activities that will yield the greater returns. To me, those activities are software intensive and I have yet to see evidence that hardware-centric companies "get it" when it comes to software. When I run around honking like a goose about this topic I am usually met with the statement that "We are a hardware company. It has made us all plenty of money in the past, so why mess with success?" To my myopic friends I say, "Just because you're naked, that don't make you an emperor."
Unfortunately there are a lot of people involved in strategy activities that do not understand the process. From what I have observed developing business strategy is sort of like teenage sex...
1. It is on everybody's mind all the time
2. Everyone talks about it all the time
3. Everyone thinks everyone else is doing it
4. Almost no one is really doing it
5. The few who are doing it are:
- Doing it poorly,
- Sure it will be better next time,
- Not practicing it safely.
I emphasize the word 'strategy' in this context because the effort is long term and a "bet the business" decision. When I use the word 'strategy' I mean a defined plan of action that will develop a business unit's competitive advantage and compound it.
I think there is a tendency to confuse strategic long range planning processes and the their outputs as strategy-making and strategy, respectively. I would submit that in their present form most of what I have seen more closely resemble mechanized marketing activities as opposed to development of a concrete plan to act and leverage competitive advantages for compounded revenue growth. Could it be that we just might be spending too much time trying to ring the cash register and too little time thinking about the long-term directions we should be taking and the technologies, resources, etc., we are going to need to get there?
I have seen lots of great long-range plans to build way cool technologies, but very few plans that show how the technologies already in place (or to be built) can be leveraged into an architectural franchise. Folks, bad technology and good strategy will always beat good technology and bad strategy. Just look at the success of Microsoft. From a software architectural perspective, the Windows operating system is an abomination. Definitely bad technology, but, oh my, what a wonderful strategy is behind it, no?
To build a platform level architectural franchise, a company is going to have to wage quite a battle in the marketplace. Market position as a hardware supplier will not give a company a significant advantage until it has closed the credibility gaps in those areas outside of the hardware business it chooses to enter. The operating system competition we are witnessing today between Microsoft and the open-source community are really architectural wars. As we are seeing or have seen, the architecture battles a company must choose will consist of one of four options:
1. fight them
2. become a countervailing power in a non-competing space
3. exit the space (alive or dead)
4. compete on implementation
So what should a company be doing to be ready to do compete and to win? To win any architecture competition, a business unit must sign up to a long-term, bet the business strategy and not be short-sighted because of near-term needs for cash flow. The components of such a long-term strategy must include:
1. A commitment to architect the state space and our products- backed by money, time, and talent with executive management backing.
2. Excellence in initial products- this is critical or you become the next Visicalc or Iridium, that is, you become the first to prototype a market for someone else to own (note: being first is not always a winning strategy). And remember, excellence is not defined by the technologist, it is defined by the user.
3. A plan for diffusion, versus retained control, across the market to establish leadership- as the architectural franchise opportunity takes shape contenders will appear offering the chance for alliances, licensing, and early architected products. This is one of the most difficult architectural challenges best met with a selectively open design; near seamless compatibility with supporting point products and commodity components; and wide, but carefully managed licensing.
4. Establishing and maintaining strong allegiances with after market products and users- supported by a broad, complex supporting infrastructure to increase switching costs, e.g., lots of toolkits with significant examples that reduce the customer's time to money.
5. A plan for harvesting and extending the existing architecture (most companies cannibalize themselves too late)- expansion and enhancement of architectural coverage while tightening proprietary control, yet leaving the architecture open and available. This means the architecture must be extensible enough to be extended from the initial niche into a steady stream of architected product lines and not just a series of point products. Static architectures will be devoured by clones!
6. Eventual architectural replacement- as the architecture ages develop new layers atop it to facilitate migration of its users and products to a new architecture, thus giving the new architecture a jump start on a new diffusion cycle. But before you throw the baby out with the bathwater, consider this story.
When Motorola first got into the GSM cellular business, it went out and purchased some protocol stacks thinking this would get them to the market quickly. Next it created its own "exec", a lean operating system kernel. It got both of these strategies backwards. The cellular protocol architecture is so interwoven with an overall system software architecture that to not have complete control over it means you are forever at the mercy of the supplier's own design. In effect, Motorola bought into a bunch of accidental complexities that ultimately led to a discard of this software and development of the complete stacks in house.
The exec design never met performance expectations and did not anticipate the future demands of new services not yet dreamed about. It, too, had to be discarded and replaced with an off the shelf product.
The point here is that the operating system was not the driver of the value add of the company's products. It supplied the usual services, but was something that any number of products on the market could do. There was no need to develop a new one in house. The protocol stacks, however, ubiquitously touched nearly every major software subsystem, yet the development team had no control over this design and had to dilute system strategies to accommodate the third party vendor's design. In effect, the tail was wagging the dog.
Like the item above implies, a company must hold onto the sand that becomes the pearl. All else can be bought on the open market, but we cannot afford to give up on an unfair advantage made possible by having complete control over a system architecture. This yields minimum accidental complexity and maximum chance for establishing an architectural franchise.
7. Intellectual property management- essential at every stage of the life cycle of the architecture and implies careful patent preparation and constant monitoring and enforcement.
Thanks for sticking with me this far. So, to conclude, what is the message here? Selling microprocessors, chipsets, motherboards, etc., is a credible first step, but companies must start planning and acting now for the follow on activities that will yield the greater returns. To me, those activities are software intensive and I have yet to see evidence that hardware-centric companies "get it" when it comes to software. When I run around honking like a goose about this topic I am usually met with the statement that "We are a hardware company. It has made us all plenty of money in the past, so why mess with success?" To my myopic friends I say, "Just because you're naked, that don't make you an emperor."
Intel's One Percent Solution
No doubt you have all heard the news of Intel's plans to let 1000 managers go from the company. As one of those managers I received the personal news by phone call in July.
If you are expecting a bitter rant about management nearsightedness or the loss of talented folks versus fixing the decision making processes at Intel, you will be disappointed. As I have noted in an earlier post I liked my job and working for Intel. I gave the seven years of my life and fully intended to give it another twenty or so more.
Once news of my impending departure spread, I received some very kind words of encouragement from friends and colleagues:
- Oh man. I’m sorry. You’re one of the good eggs.
- That is terrible news, not only for you and your family, but for those people who’ll remain after all the dust settles. We will miss your insight, vision, and contributions greatly here.
- A lot of my friends got tagged and it is a strange time as I feel they were very talented people as you are.
- I am very sorry to read that you are a victim of the ‘night of the long knives’. Doesn’t appear to be any rhyme or reason to this purge. My immediate manager was discharged yesterday morning and is already gone. This action was executed just as the team he was brought in to lead last year, was finally becoming effective -- having a vision and a focus for the first time since I’ve been on it.
I’ve much appreciated your vision, insight and forbearance (especially) during my working career at Intel. You’ve certainly well role modeled the values of a successful entrepreneur and professional engineer (as well as those claimed by Intel). And we all have appreciated your willingness to mentor, counsel, and blog.
While I have no doubt that you will emerge from this event successful and better off than you have been recently with Intel, Intel has taken an unrealized substantial loss in its decision to do without your services. Certainly, looking back, if management had heeded your and other cellular leaders’ advice, they would not have found it necessary to sell off a money losing operation (because it would have been making money and in charge of its own destiny).
- Arrhh, matey – sorry to hear the news. It’s been a pleasure to have plundered witcha’ as a fellow pirate. May your bounty chest remain full ‘o gold pieces and the wind always fill your sails.
- Intel will surely be missing out on a great manager. I’d have to say that in my 10 years, you were up there at the top in terms of being the best manager I had the pleasure working with. Not sure if I ever told you that.
- Sorry to hear about that. Doesn't make sense to me really given your dual role as soldier / captain.
- This is indeed very sad news! It was fun and great learning experience working with you.
- Not sure if I should congratulate you or send my condolences.
- Oh my god, that is really sad to hear. Don’t know what to say. We’ll definitely miss you.
- This is a really screwed up place for letting people like you go. I met one of your previous direct reports here... We both agreed you had a unique management style and vision. OK, you were not the easiest to work for (smile), but both agreed that you were the best Intel manager we ever had.
Kind words indeed, and made the news that I would be leaving Intel even more bittersweet.
Intel's decision to start with managers in its long term plan to get leaner and more agile was a smart move. I think it sends a message to the company's employees and shareholders that Paul Otellini, CEO, is serious about taking the company to the next level. From what I have seen inside the company, there was a great deal of personal anguish and hand-wringing by those that had to made the decisions about who was going to be asked to leave the company.
Despite being on the receiving end of the news, I don't envy the individuals that made these decisions. The majority of managers at Intel were once very successful individual contributors, so the company is losing some serious learning curve experience in the 1000 managers being let go this month. That said, the move opens up opportunities for new blood in the ranks and goes a long way in reducing the decision making bloat that Intel has been wrestling with in the last five years of rapid employee growth.
If you are expecting a bitter rant about management nearsightedness or the loss of talented folks versus fixing the decision making processes at Intel, you will be disappointed. As I have noted in an earlier post I liked my job and working for Intel. I gave the seven years of my life and fully intended to give it another twenty or so more.
Once news of my impending departure spread, I received some very kind words of encouragement from friends and colleagues:
- Oh man. I’m sorry. You’re one of the good eggs.
- That is terrible news, not only for you and your family, but for those people who’ll remain after all the dust settles. We will miss your insight, vision, and contributions greatly here.
- A lot of my friends got tagged and it is a strange time as I feel they were very talented people as you are.
- I am very sorry to read that you are a victim of the ‘night of the long knives’. Doesn’t appear to be any rhyme or reason to this purge. My immediate manager was discharged yesterday morning and is already gone. This action was executed just as the team he was brought in to lead last year, was finally becoming effective -- having a vision and a focus for the first time since I’ve been on it.
I’ve much appreciated your vision, insight and forbearance (especially) during my working career at Intel. You’ve certainly well role modeled the values of a successful entrepreneur and professional engineer (as well as those claimed by Intel). And we all have appreciated your willingness to mentor, counsel, and blog.
While I have no doubt that you will emerge from this event successful and better off than you have been recently with Intel, Intel has taken an unrealized substantial loss in its decision to do without your services. Certainly, looking back, if management had heeded your and other cellular leaders’ advice, they would not have found it necessary to sell off a money losing operation (because it would have been making money and in charge of its own destiny).
- Arrhh, matey – sorry to hear the news. It’s been a pleasure to have plundered witcha’ as a fellow pirate. May your bounty chest remain full ‘o gold pieces and the wind always fill your sails.
- Intel will surely be missing out on a great manager. I’d have to say that in my 10 years, you were up there at the top in terms of being the best manager I had the pleasure working with. Not sure if I ever told you that.
- Sorry to hear about that. Doesn't make sense to me really given your dual role as soldier / captain.
- This is indeed very sad news! It was fun and great learning experience working with you.
- Not sure if I should congratulate you or send my condolences.
- Oh my god, that is really sad to hear. Don’t know what to say. We’ll definitely miss you.
- This is a really screwed up place for letting people like you go. I met one of your previous direct reports here... We both agreed you had a unique management style and vision. OK, you were not the easiest to work for (smile), but both agreed that you were the best Intel manager we ever had.
Kind words indeed, and made the news that I would be leaving Intel even more bittersweet.
Intel's decision to start with managers in its long term plan to get leaner and more agile was a smart move. I think it sends a message to the company's employees and shareholders that Paul Otellini, CEO, is serious about taking the company to the next level. From what I have seen inside the company, there was a great deal of personal anguish and hand-wringing by those that had to made the decisions about who was going to be asked to leave the company.
Despite being on the receiving end of the news, I don't envy the individuals that made these decisions. The majority of managers at Intel were once very successful individual contributors, so the company is losing some serious learning curve experience in the 1000 managers being let go this month. That said, the move opens up opportunities for new blood in the ranks and goes a long way in reducing the decision making bloat that Intel has been wrestling with in the last five years of rapid employee growth.
Performance Reviews - What Really Matters
When I was a manger of technologists at Intel, Motorola, and in my own company, each year I would summarize the performance areas that got attention in our annual performance ranking and rating sessions. Here is a list (not in any order) of some of the items that mattered:
- project work that exceeded expectations in output and/or scope
- strong team leader or key contributor to department wide projects or task forces
- effectively managed assigned projects/tasks
- major contributor to one or more strategic projects that had business impact
- valued contributor to strategic forums
- high quality deliverables
- operational excellence, i.e., meets commitments on time or ahead of schedule; deliverables delight customers
- excellent manager of employees; increased team's bench strength, cohesion and output
- mentoring, teaching and/or training others
- saw a problem and owned it until it was solved
- managed expectations effectively - no surprises
- personal agenda was focused on the organization and not the individual
- became an expert in another area outside their normal expertise
- was frequently sought out by others because of their expertise AND their teamwork behaviors
- communicated effectively with managers (kept them in the loop) and with rest of the organization
- cleans up an organizational mess or is willing to take on a hard job or extra workload
- demonstrates a proactive attitude: not waiting to do what needs to be done, even if outside their comfort zone; is willing to take the risks to pull the organization forward
- strong personal network; forged stronger ties; and works effectively across business groups
role models company values
If you are a manager, the next time someone asks you about performance expectations, whip out this short list for the start of a very fruitful discussion. If you are being managed, and who isn't, review this list and compare it to your own performance practices. It is a good start towards the golden “Outstanding” rating (i.e., firing on all cylinders & exceeding expectations on them all, too).
- project work that exceeded expectations in output and/or scope
- strong team leader or key contributor to department wide projects or task forces
- effectively managed assigned projects/tasks
- major contributor to one or more strategic projects that had business impact
- valued contributor to strategic forums
- high quality deliverables
- operational excellence, i.e., meets commitments on time or ahead of schedule; deliverables delight customers
- excellent manager of employees; increased team's bench strength, cohesion and output
- mentoring, teaching and/or training others
- saw a problem and owned it until it was solved
- managed expectations effectively - no surprises
- personal agenda was focused on the organization and not the individual
- became an expert in another area outside their normal expertise
- was frequently sought out by others because of their expertise AND their teamwork behaviors
- communicated effectively with managers (kept them in the loop) and with rest of the organization
- cleans up an organizational mess or is willing to take on a hard job or extra workload
- demonstrates a proactive attitude: not waiting to do what needs to be done, even if outside their comfort zone; is willing to take the risks to pull the organization forward
- strong personal network; forged stronger ties; and works effectively across business groups
role models company values
If you are a manager, the next time someone asks you about performance expectations, whip out this short list for the start of a very fruitful discussion. If you are being managed, and who isn't, review this list and compare it to your own performance practices. It is a good start towards the golden “Outstanding” rating (i.e., firing on all cylinders & exceeding expectations on them all, too).
Architecting Opus or Reilly's Architecting Truths
I spent about fifteen of my twenty plus years of engineering as a hardware and software architect, creating high level designs for implementation. The term architect leaked into the pop culture with The Matrix movies:
Neo: Who are you?
Architect: I am the Architect. I created the Matrix. I have been waiting for you. You have many questions and although the process has altered your consciousness you remain irrevocably human, ergo some of my answers you will understand and some of them you will not. Concordantly, while your first question maybe the most pertinent you may or may not realize it is also the most irrelevant.
Bumper stickers for architects:
Brook’s Mythical Man-Month: [T]he complete and detailed specification of the user interface.
Mack Alford, Ascent Logic: Dual problem of translating user needs into system requirements and the specification of components, that when integrated, will satisfy those requirements.
James Rumbaugh, Object-Oriented Modeling and Design: The overall structure of a system, including its partitioning into subsystems and their allocation to tasks and processors.
Neo: Who are you?
Architect: I am the Architect. I created the Matrix. I have been waiting for you. You have many questions and although the process has altered your consciousness you remain irrevocably human, ergo some of my answers you will understand and some of them you will not. Concordantly, while your first question maybe the most pertinent you may or may not realize it is also the most irrelevant.
Bumper stickers for architects:
Real architects do it at high levels OR Real architects describe it but never do it
What others say about architecting:
Webster’s Ninth Collegiate Dictionary: The art or practice of designing and building structures and especially habitable {workable} ones.
What others say about architecting:
Webster’s Ninth Collegiate Dictionary: The art or practice of designing and building structures and especially habitable {workable} ones.
Brook’s Mythical Man-Month: [T]he complete and detailed specification of the user interface.
Mack Alford, Ascent Logic: Dual problem of translating user needs into system requirements and the specification of components, that when integrated, will satisfy those requirements.
James Rumbaugh, Object-Oriented Modeling and Design: The overall structure of a system, including its partitioning into subsystems and their allocation to tasks and processors.
We have all experienced the failure brought on by bad architecting, but we usually do not discover this until it is too late. And often, the fact that the underlying architecture of a product is the root cause of a project/product failure is never realized. A study conducted by the Standish Group of over 8,000 telecom projects revealed the following results:
Failure Statistics
31% of projects will be canceled before completion
53% of projects will cost 189% of their original estimates
9% of large company projects are done on time and on budget
Completed projects have only 42% of originally proposed features and functions
(*No flames please, I know there is a competing study by the Cutter consortium published in 2005 that disputes these dismal statistics.)
I am convinced that bad architectures were underlying many of these failures, cost overruns, etc.
In an ideal world, architecture definition is easy. As Charlton Heston said to Yul Brynner in The Ten Commandments (1956), “So shall it be written, so shall it be done." In other words, once I have created an architectural specification, I would like to think that implementors will build it as I have so specified. But in the real world we know that this never happens as competing agendas, egos, and strategies get in the way.
What is it exactly that architects do anyway? And what are some identifiable aspects of good architectures? I will answer these questions in a few lines, but first let's set the architectural context:
REQUIREMENTS are concerned with the determination of the information, processing, and the characteristics of that information and processing needed by the user(s) of the product
ARCHITECTURE is concerned with the selection of HW/SW architectural elements, their interactions, and the constraints on those elements and their interactions necessary to provide a framework in which to satisfy the requirements and serve as a basis for the design
DESIGN is concerned with the modularization and detailed interfaces of the HW/SW design elements, their algorithms, signals, and procedures, and the data types needed to support the architecture and to satisfy the requirements; and
IMPLEMENTATION is concerned with the representations of the algorithms, signals, and data types that satisfy the design, architecture, and requirements
So, we can define architecting formally as the process by which user requirements, having been translated into technical requirements, are embodied into a synergistic collection of physical and logical entities, and their interfaces that exhibit…
wholeness, reflecting the primacy of the architecture as a whole over its elements
hierarchy, reflecting not only the potential for successive decompositions, but also the role of a given architecture as a subsystem within a larger framework; and
relativity, reflecting the inadequacy of any single delineation of an architecture and the consequent necessity of resorting to classes of descriptions, any one of which can capture only certain aspects of the wholeness and hierarchy of the system.
Given all the above, we now answer the question, “What do architects do?”
Hint Number 1:
By inspection, find the roots of the following polynomial:
(Equation 1) X^4 - 9x^3 + 27x^2 - 31x + 12
Hint Number 2:
By inspection, find the roots of the following:
(x - 1)^2 (x - 3) (x - 4)
Hint Number 3:
Finding the roots of the previous equation was not easy until we eliminated the accidental complexity by factoring, thereby leaving only the essential complexity
X^4 - 9x^3 + 27x^2 - 31x + 12 = (x - 1)^2 (x - 3) (x - 4)
The answer, then, is that architects factor complexity.
And what is a “good” architecture? Good architectures have optimum essential complexity, minimum accidental complexity, and exhibit a conceptual integrity that is normally visible by inspection.
Conceptual integrity means that:
- The design reflects one set of ideas: a single philosophy
- Systems that have it are simple and straightforward
- Springs forth from a very small number of resonant minds
- Requires a chief architect to control the concepts
- Facilitates parallel architectural and implementation activities
- Nevertheless, vigilance by the architect is required once implementation has begun
Thanks for staying with me this far. Now for the big finish. Here are
Reilly's Architecting Truths:
- An architecture must possess conceptual integrity - appear to be the product of one mind and written by one hand.
- It must be implementable in a cost-effective manner. Distrust an architecture that has not been implemented. Distrust an architect that has not been an implementor. Be wary of an architecture that has not been used by people other than its architect and implementers.
- It is better for an architecture to be wrong than to be imprecise; the former can be fixed, the latter may never be spotted. Specifications should be written in the singular, not plural.
- Each interface function should be as general as possible while also consistent with efficient implementation. For example, it should be independent of representation media. E.g., it should provide general mechanisms from which alternative policies can be implemented.
- An interface should hide information - it must reveal the "what" a system does but never the "how" the system does it.
- Partitioning is done so that each interface is "skinny" - it requires minimum information to be exchanged across it.
- Essential complexity should be managed in those components that are of concern to the fewest people possible.
- A strong match between functional and physical structures should be present.
- Functional aggregation should result in a partitioning of elements that will have very low external complexity and very high internal complexity.
- Distributed systems should have slowly changing global activity and rapidly changing local activity.
- Performance of partitioned elements should be insensitive to unknown or uncontrollable external influences.
- Impacts of extreme pathological behavior of a partitioned element to another element should be minimal.
- Deviations in product cost, schedule, technology, customer needs, and/or performance should have minimal impact upon the design of the architecture. That is, the degree to which developers must modify applications or the architecture itself to meet unforseen external changes is a measure of hidden accidental complexity.
- The ratio of Upper Layer or Lower Layer primitives should be much less than unity. This is a strong indicator of minimized complexity across elements and a high degree of abstraction.
- The ability to debug new applications directly on a working system, without affecting customers using that system, is a strong measure of architectural goodness.
- Bad cooking can at least be thrown away, but bad architecture is much harder to dispose of. (Kevin Kahn, Intel Fellow)
If you call yourself an architect then I hope you agree with today’s post. If you do not, I would like to hear from you.
Why I Liked My Job at Intel Corporation
Last September, after seven good years at Intel Corporation I was, ahem, downsized, as part of a broad corporate restructuring. I am not bitter about this. On the contrary, I will miss my job.
I often read the posts to Intel internal web pages as well as many of the company blogs. I was always dismayed by the number of people around the company who appeared to be very unhappy. They are unhappy with their management, their co-workers, and their work. Some cross the line between just venting and become cynics. Frankly, as a manager, I think cynicism is a firing offense. A cynic will undermine anything a group is trying to achieve. Nothing anyone does satisfies these persons. All decisions made are candidates for revisitation and undoing. Cynics are a pernicious virus in any organization that should be eliminated. How do you know you are becoming a cynic?
I left work every day frustrated. I was frustrated that I didn't have enough hours in the day to do everything I would have liked to do. I was frustrated that I sometimes have to get out of the zone and put down my laptop to tend to the other demands of life, such as eating, running errands, and working around my home. My frustration was a positive outgrowth of my excitement for my job at Intel. It was a job that challenged all my mental faculties, forcing me to immerse myself in new domains daily, and I had the privilege of working with (and managing) very bright individuals. Sure, I had complaints, but they are mostly related to keeping me from being more effective. And yes, my boss and I clashed from time to time. This was more a symptom of two individual "take no prisoner" work attitudes repelling one another and not from some personal dislike.
To answer the question posed above, when you find yourself leaving work each day mad you are on the slippery slope towards cynicism. I sensed this in the many of the items I had been reading from others. These persons are mad at everything around them and don't mind telling anyone who will listen. To those individuals I would counsel, when you find yourself in this situation, the time has come for you to either find a new job within the company, or start looking elsewhere.
Leave work frustrated, not mad.
I often read the posts to Intel internal web pages as well as many of the company blogs. I was always dismayed by the number of people around the company who appeared to be very unhappy. They are unhappy with their management, their co-workers, and their work. Some cross the line between just venting and become cynics. Frankly, as a manager, I think cynicism is a firing offense. A cynic will undermine anything a group is trying to achieve. Nothing anyone does satisfies these persons. All decisions made are candidates for revisitation and undoing. Cynics are a pernicious virus in any organization that should be eliminated. How do you know you are becoming a cynic?
I left work every day frustrated. I was frustrated that I didn't have enough hours in the day to do everything I would have liked to do. I was frustrated that I sometimes have to get out of the zone and put down my laptop to tend to the other demands of life, such as eating, running errands, and working around my home. My frustration was a positive outgrowth of my excitement for my job at Intel. It was a job that challenged all my mental faculties, forcing me to immerse myself in new domains daily, and I had the privilege of working with (and managing) very bright individuals. Sure, I had complaints, but they are mostly related to keeping me from being more effective. And yes, my boss and I clashed from time to time. This was more a symptom of two individual "take no prisoner" work attitudes repelling one another and not from some personal dislike.
To answer the question posed above, when you find yourself leaving work each day mad you are on the slippery slope towards cynicism. I sensed this in the many of the items I had been reading from others. These persons are mad at everything around them and don't mind telling anyone who will listen. To those individuals I would counsel, when you find yourself in this situation, the time has come for you to either find a new job within the company, or start looking elsewhere.
Leave work frustrated, not mad.
Subscribe to:
Posts (Atom)
