You can smell it in the air. When a good idea's time has come, many people will start working on it, almost spontaneously. That's what happens when smart people have the right to make choices and decisions. Good things happen.
This happens at Microsoft. More often that I can explain. Not everyone sees it. Not everyone knows where to look, but I've seen it... more than once.
I've seen an idea just 'arrive,' get tested, and fall away. If the idea is a good one, it comes back and comes back and comes back until more and more people start to BELIEVE in it. The idea takes over. After a while, no one can remember what it was like before that idea was reality. This was the way it was before code analysis tools appeared. The idea appeared and was tried many times: automatically search code for defects and weak practices (think LINT on steroids). After a while, it caught on, and now, a decade later, I can't find anyone who remembers what it was like to write a major product without code analysis tools.
Yes, in a healthy culture of innovation, a good idea will keep coming back.
However, when the time comes, if your team has a role to play, jump in. Don't hang out and wait to see if the idea was any good. If you fail to take the lead, others will take it away from you.
Case in point: Enterprise Architecture is a fairly new thing in Microsoft IT. While there have been architects for a long time, the current model, where architects actually have a say in large projects and can direct the adoption of expensive but valuable infrastructure... this is relatively new. Shortly after EA started to get their traction, one of the embedded architects started to form an Architectural Review Board (ARB) in his area. He backed off because he didn't have the governance support, but the idea was right.
Now, other folks want to create Architectural Review Boards. The idea has arrived. It is time for the Enterprise ARB to take shape. It is time to develop the decision rights, processes, and pro forma models that produce value by creating and enforcing excellence in architecture.
Now is the time for EA to step in and take a leadership role in creating these boards. If we don't, the project management team will. Now, don't get me wrong. Our PM team is staffed with very smart birds. But it is our leadership that is needed. If we fail to act, the board that they create could be weak and potentially ineffective. Or worse, it could make decisions that aren't architecturally sound or based on principles.
As they say, timing is everything. It is time to lead.
Architects don't write code. That's the first thing that a developer notices when he or she moves into this job. But there is another change... substantial yet subtle... Architects don't accomplish anything without having someone else 'doing the real work.'
This is not that different from project managers and development managers. You have to move from the individual contributor role to that of leader and, to an extent, manager. However, this is not leadership by "I said so." Very few developers report directly to an architect. This is leadership by, well, leadership. You have to influence the decisions of others without having direct control over them.
Since you have no direct control, Leadership skills matter a great deal to the architect. You have to show that the team has common goals, and sell those goals. You have to share ideas, build credibility, set a direction and help each person to know how they can help the team to reach it.
Find the passionate among you. Most people are passionate about something. There is some aspect of their job that they love. Find it. Speak with them. Go to lunch. Share ideas. Brainstorm. Listen.
Find their passion and harness it. Show them how their passion can become their job. They will follow you into battle if they believe in the goal and their role in it and are passionate about their role. Developers will follow if they believe you can lead.
Definition: An architectural model is a rich and rigorous diagram, creating using available standards, in which the primary concern is to illustrate a specific set of tradeoffs inherent in the structure and design of a system or ecosystem. We use architectural models to communicate with others and seek peer feedback.
Let's look at that definition a little:
I don't know why I felt compelled to write this definition today. I guess it's just Sunday. Alas.
There's lots of different ways to describe data. I've seen data models that attempt to describe, conceptually, all of the data relationships for lines of business, marketing programs, fulfillment programs, etc. Conceptual data models are useful, primarily because they give you a starting point to work with the business to first understand, and then communicate, how the data can represent the business' requirements.
Normally, when creating a system, we drop down to a logical data model for that system. We indicate the "data on the inside" and the "data on the outside". Effectively, the diagram starts with a large 'box'. Inside the box are entities needed by the application. Outside are the entities that come from somewhere else but are referenced by the application.
One challenge, however, that appears to be stumping one of my team mates is how to create the conceptual model when there is not one system, but two or three systems that communicate. Effectively, we are talking about a distributed system, with distributed data. The data is not distributed because of geography, but rather in order to foster loose coupling.
This is a different way to look at the design of a system than is typically seen, but I feel pretty strongly that it is an important aspect, and one that we need to be fairly formal about.
I approach the systems from the standpoint of the business processes first, and the use cases second. For example, if you are creating a system that facilitates the creation of a standard business contract, it is entirely reasonable to break down the process into steps, where each step is performed by different roles.
First step would be to define a marketing or fulfillment program that the contract will be tied to. Second would be to create legal clauses that can be fit into the document. Third would be to create a template with rules for how the clauses are to be assembled for the particular contract type, and fourth would be to create the contract itself. Different people perform each step. Each step has distinct responsibilities. You could, if you wish, create a seperate system for each. In a SOA world, I think that you would create a set of services for each.
Each set of services is, in itself, an independent system. In order to remain decoupled, the data may be referential, but not coupled. Therefore, you may need to add a customer before you add an invoice, but there is NO reason that adding a customer should create data records directly in the order management database (I'm being a purist... Master Data Management is the 'reality' behind this situation).
So, if you are a developer who is used to creating a database with every bit of data that you think you will need in it, it can be quite a change to create not one, but many databases, bound together by master data that is copied locally on demand, and kept up to date by a cache engine (MDM).
Now, take one of those developers and ask him or her to create a data model that illustrates not "data on the inside" but "data in each room". That requires a different kind of thinking... because now, the problem of 'master data' becomes visible (and a little painful).
In this model, the Product data is brought across both for invoices and for shipments, but is it really the Product data that is in the shipments, or is it product and lot data. In other words, it is one thing to ask "who did we ship soap to," and another thing altogether to ask "who did we ship Lot 41 of tainted beef to?"
This distinction, between product and lot, becomes particular visible when you model your systems this way, but more importantly, you can see the lines that cross the boundary between systems, and you can place services on each line: get product, get lot, get invoice, get shipment
When designing the database, you will need to use a replication or cache or transactional store to insure referential integrity.
I'm a collaborative person, and most of the time, I'm quite content to make sure that other folks get the credit for little victories that I participate in, especially when that improves my relationship with them.
However, every now and then, it is important to claim credit for a success, especially if I can leverage it into "making my manager look good."
Enterprise Architecture walks a tight rope. We are seen as obstructionist and difficult by some, ineffective and pointless by others. The key is to stay close to the middle: involved, valuable, empowering. To be seen there, it is important... nay, critical... that big successes that Enterprise Architecture really did have an effect on are visible to senior staff and the CIO.
That's a challenge, because our culture is odd this way. In the Microsoft culture, a failure is always one person's fault, but a success is shared by all. I don't know if this is intentional, but in an environment filled with competitive, intelligent, shrewd business people, it is somewhat inevitable. That makes it hard to hit that 'balanced success' point without looking like you are trying to steal someone else's good press.
The answer is to say "we did this together... and this was OUR ROLE, and it was important." You can't make one of the other folks look bad in that, because you need them to keep working with you, even if they fought against you every step of the way. So success is still shared, but the role of the organization is recognized.
EA needs all the positive press it can get.
I was reading some of the newsgroups and, for some reason, I've seen a LOT of requests lately about "interview questions for 'blah-de-blah' position." Just saw another for .Net developers. Made me wonder, what would I consider is a good set of interview questions for an Enterprise Architect?
Let's see... what would I look for in an enterprise architect?
Of course, you can't ask questions about every area, so you want to pick the particular areas that you think are indicative of the experience you need in the particular position, or which you think can lead to a tangent that may cover other areas. For example, a discussion of Business Intelligence enablement in an application infrastructure will hit on ETL, BI data management, and operational data management, but may also tangent into a good discussion of authorization at the data level, which can segue into a discussion of general authentication and authorization discussions.
Similarly, a discussion of networking and load balancing can lead to a tangent on HTTPS and right into the Public Key Infrastructure.
Public speaking is probably the hardest to wrangle in an interview. You can pull off 'small group presentation' by having them draw, on a white-board, the conceptual application architecture of a system that they are familiar with and walk you through the system, discussing tradeoffs, strengths, weaknesses, and things you'd do differently if you could rewind time. (Note: if they fail to reflect on any regrets, flip the 'bozo bit.' No one needs an arrogant or self-righteous Enterprise Architect).
Probably the least necessary is the ability to describe software development methodologies. Architects can be interested in, even passionate about, Scrum or RUP or TDD, but they have little to do with the ability to do the job.
So, while I didn't describe any specific questions, I hope that someone looking to interview an Enterprise Architect can benefit from this profile and notes. At the end of the day, one company's ideal candidate is a poor fit for another. At this level, the interview needs to be driven by proven abilities and past experiences, and not book learning.