Twenty Habits of Ineffectual Leaders

Since starting this blog I have resisted the temptation to rant about past jobs and the people I have encountered in these positions. Many blogs are a place for lots of sour grapes, or just living in the past to assign blame. But a recent article in Business Week, Bad Habits That Can Hold You Back, struck such a chord with me that I feel compelled to devote some words to it in this posting.

Below are the twenty bad habits of ineffectual leaders identified in the BW article.

Winning Too Much: The need to win at all costs and in all situations—when it matters, when it doesn’t, and when it’s totally beside the point.

Adding Too Much Value: The overwhelming desire to add our two cents to every discussion.

Passing Judgment: The need to rate others and impose our standards on them.

Making Destructive Comments: The needless sarcasms and cutting remarks that we think make us sound sharp and witty.

Starting with “No,” “But,” or “However”: The overuse of these qualifiers, which secretly say to everyone, “I’m right. You’re wrong.”

Telling the World How Smart We Are: The need to show people we’re smarter than they think we are.

Speaking When Angry: Using emotional volatility as a management tool.

Negativity: The need to share our negative thoughts, even when we weren’t asked.

Withholding Information: The refusal to share information in order to maintain an advantage over others.

Failing to Give Proper Recognition: The inability to praise and reward.

Claiming Credit We Don’t Deserve: The most annoying way to overestimate our contribution to any success.

Making Excuses: The need to reposition our annoying behavior as a permanent fixture so people excuse us for it.

Clinging to the Past: The need to deflect blame away from ourselves and onto events and people from our past; a subset of blaming everyone else.

Playing Favorites: Failing to see that we are treating someone unfairly.

Refusing to Express Regret: The inability to take responsibility for our actions, admit we’re wrong, or recognize how our actions affect others.

Not Listening: The most passive-aggressive form of disrespect for colleagues.

Failing to Express Gratitude: The most basic form of bad manners.

Punishing the Messenger: The misguided need to attack the innocent, who are usually only trying to protect us.

Passing the Buck: The need to blame everyone but ourselves.

An Excessive Need to Be “Me”: Exalting our faults as virtues simply because they exemplify who we are.

I once had a boss that exhibited nearly all of these bad behaviors. It was one of the most debillitating experiences of my professional career. No matter how hard I worked or what I accomplished, I remained in the shadow of this person's ego and indifference. Yet I continued to work for this person because I labored under a naïve notion that he would be found out by the company and be summarily dismissed or demoted. My mistake was to not move onward as soon as I recognized these symptoms. I enjoyed the work I was doing but ignored the effect this boss was having on my personal and professional life. To this day my family and I cringe whenever this person's name is mentioned.

If you see your boss or company management exhibiting the behaviors above, it is time for you to start looking around for something better.

USPTO Patent Performance in 2006

Source: <http://www.uspto.gov/web/offices/com/speeches/06-73.htm>

"Patent examiners completed 332,000 patent applications in 2006, the largest number ever, while achieving the lowest patent allowance error rate -- 3.5% -- in over 20 years. At 54%, the patent allowance rate was also the lowest on record. [See Figure below] Patent allowance rate is the percentage of applications reviewed by examiners that are approved."

"The USPTO received in excess of 440,000 patent applications in 2006, a record number. To help meet the demand, the agency hired a record 1,218 patent examiners, exceeding its goal by more than 200 people. To support this dramatic hiring increase, the USPTO replaced its one-on-one training model with a university approach for new hires. This allowed the agency to deliver comprehensive training to new examiners, while more experienced examiners and supervisors focused on quality examination. The agency will continue to hire over 1,000 patent examiners each year for the next five years. Even so, the volume of applications will continue to outpace the agency's capacity to examine them. USPTO continues to look for ways, beyond hiring, to reduce the backlog, while maintaining examination quality. "

Working at home: "The first 500 patent examiners began working from home four days a week, using a hoteling program to book office space the one day a week they are in the office. The agency expects that an additional 500 examiners will be added to those already working from home each year for at least the next five years."

From the numbers above, we see that the USPTO is receiving more patent applications than they are completing, i.e., the USPTO is completing one application for every 1.32 applications received. From 1997 to 2006, the number of patent applications being filed have increased by 87 percent. In 2006, the backlog of patent applications exceeded 700,000! This backlog increased the USPTO pendency (see figure below) for taking action on the submitted application.

As shown in the Figure above, USPTO first action pendency is now exceeding 22 months. Average first action pendency measures the average time in months from filing until an examiner’s initial determination is made of the patentability of an invention. Indeed, some business method patent applications have taken over ten years before issuance!

Merry Christmas and Happy Holidays

'Merry Christmas', 'Happy Holidays', or 'Happy New Year' in...


Afrikander - Een Plesierige Kerfees
Arabic - Eid Milad Majeed -or- Eid Saied or Aiad Saiedieh -or- Koul Aam Wa Inta Bekeir
Argentine - Felices Pasquas Y felices ano Nuevo
Armenian - Shenoraavor Nor Dari yev Pari Gaghand
Assamese - Natun Bacharar Subha Kamana
Azeri - Tezze Iliniz Yahsi Olsun
Basque - Zorionstsu Eguberri. Zoriontsu Urte Berri On
Bengali - Naba Bochorer Shubho Kamona
Bohemian - Vesele Vanoce
Brazilian - Boas Festas e Feliz Ano Novo
Breton - Nedeleg laouen na bloavezh mat
Bulgarian - Tchestita Koleda; Tchestito Rojdestvo Hristovo
Chinese -
(Mandarin) Kung His Hsin Nien bing Chu Shen Tan
(Catonese) Kung Cho Saint Town Kun Hall Sun Hai
Cornish - Nadelik looan na looan blethen noweth
Corsican - Pace e Salute
Cree - Mitho Makosi Kesikansi
Croatian - Sretan Bozic I Nova Godina
Czech - Prejeme Vam Vesele Vanoce a stastny Novy Rok
Danish - Gladelig Jul
Dutch - Vrolijk Kerstfeest en een Gelukkig Nieuwjaar!
English - Merry Christmas
Esperanto - Gajan Kristnaskon
Estonian - Roomsaid Joulu Puhi
Farsi - Cristmas-e-shoma mobarak bashad
Finnish - Hyvää Joulua ja Onnellista Uutta Vuotta
French - Joyeux Noel et Bonne Annee
Frisian - Noflike Krystdagen en in protte Lok en Seine yn it Nije Jier!
German - Froehliche Weihnachten
Greek - Kala Christouyenna!
Hawaiian - Mele Kalikimaka
Hebrew - Mo'adim Lesimkha. Chena tova -or- Chag Sameach and L'shana tova
Hindi - Shub Naya Baras -or- Navin Varshabhinandan
Hungarian - Kellemes Karacsonyi unnepeket
Icelandic - Gledileg Jol
Indonesian - Selamat Hari Natal
Iraqi - Idah Saidan Wa Sanah Jadidah
Irish Gaelic - Le gach dea gui i gcomhair na Nollag agus na h-Aithbhliana
Irish - Nollaig Shona Dhuit
Italian - Buone Feste Natalizie
Japanese - Shinnen omedeto. Kurisumasu Omedeto
Kannada - Hosa Varushada Shubashayagalu
Korean - Sung Tan Chuk Ha
Latvian - Priecigus Ziemas Svetkus un Laimigu Jauno Gadu
Lettish - Priecigus Ziemassvetkus
Lithuanian - Linksmu Kaledu
Manx - Nollick ghennal as blein vie noa
Maori - Meri Kirihimete
Marathi - Shubh Nava Varsh –or- Shubh Varshabhinandan -or- Navin Varshachya Shubhecchha
Navajo - Merry Keshmish
Nepali - Naaya barshako subbha kamana
Norwegian - God Jul Og Godt Nytt Aar
Pennsylvania German - En frehlicher Grischtdaag un en hallich Nei Yaahr!
Polish - Wesolych Swiat Bozego Narodzenia
Portuguese - Boas Festas
Rapa-Nui - Mata-Ki-Te-Rangi. Te-Pito-O-Te-Henua
Rumanian - Sarbatori vesele
Russian - Pozdrevlyayu s prazdnikom Rozhdestva is Novim Godom
Serbian - Hristos se rodi
Slovakian - Sretan Bozic or Vesele vianoce
Samoan - La Maunia Le Kilisimasi Ma Le Tausaga Fou
Scots Gaelic - Nollaig Chridheil agus Bliadhna Mhath Ur
Serb-Croatian - Sretam Bozic. Vesela Nova Godina
Singhalese - Subha nath thalak Vewa. Subha Aluth Awrudhak Vewa
Slovak - Vesele Vianoce. A stastlivy Novy Rok
Slovene - Vesele Bozicne. Screcno Novo Leto
Spanish - Feliz Navidad
Swedish - God Jul and (Och) Ett Gott Nytt Ar
Tagalog - Maligayamg Pasko. Masaganang Bagong Taon
Tamil - Nathar Puthu Varuda Valthukkal
Telugu - Nutana Samvatsara Subhaakaankshalu (Happy New Year to You)
Thai - Sawadee Pee Mai
Turkish - Noeliniz Ve Yeni Yiliniz Kutlu Olsun
Ukrainian - Srozhdestvom Kristovym
Urdu - Naya Saal Mubarak Ho
Vietnamese - Chung Mung Giang Sinh
Welsh - Nadolig Llawen
Yugoslavian - Cestitamo Bozic
Zulu - Sinifisela Ukhisimusi Omuhle Nomnyaka Obusisiwe
Happy holidays to everyone!

Day in The Life of a Patent Analyst

What does a person who works with intellectual property and is not an attorney do day to day? I work as a wireless patent forensic specialist. So what exactly does that mean?

Briefly, wireless technical intellectual property (IP) forensic analysis comprises the following activities: validity, invalidity, infringement, non-infringement, valuation, assertion targeting, acquisition due diligence, prior-art review, claim charts, Markman ruling assessment, Rule 11 preparation, claim construction, application ghost-writing, licensing carve-out language, and more.

More specifically the services I provide are as follows:

* Provide technical product insight to legal counsel for the protection of IP assets; serve as the technical liaison with outside law firms, for filing or protection in litigation, oppositions, and patent interferences.

* Participate / assist in worldwide patent application preparation and prosecution.

* Assist in preparation and prosecution patent applications before the USPTO.

* Review and conduct patent searches, and prior art searches for patents involving semiconductor technology and other technology related patents.

* Assist in the legal and factual research and, review and edit pleadings, applications and other technical and legal documents in connection with a variety of intellectual property issues.

* Assist in procuring rights to technology and participate in due diligence reviews.

* Assist in managing licensed-in filings from acquired companies; coordinate with licensor's attorneys to secure patents.

* Help analyze patents and prepare infringement, validity, and freedom-to-operate opinions, including working with outside counsel.

*Assist in developing clients' strategy on how they can develop an area, strengthen patents and work around roadblocks in patents.

* Counsel clients through participation in various levels of R&D and other cross-functional team meetings.

* Identify research subject to filing of patent applications.

* Conduct educational seminars with internal staff on technology and intellectual property.

* Help review agreements such as material transfer agreements.

As inferred, my daily life is basically a solitary activity using my resources gained from over two decades of experience in the wireless telecommunications industry. In a subsequent blog entry I will take a deeper dive showing the reader how I go about dissecting a patent for use by intellectual property attorneys use in offensive or defensive matters.

Three Things to Ask Your Manager Every Month

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!

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."

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.

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).

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:

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.

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.