Leadership
Looking Beyond Yourself
Mar 3rd
It’s been weeks since I have been able to gather my thoughts and put out something meaningful into the blogosphere. The scale of the technology migration we’re planning is really showing as we identify all the pieces that will be needed. Migrating 30 years of work is no small task and the pressure is definitely on. We’ve been having some fun with it as that is one way to mitigate the stresses we feel. We now refer to ourselves privately as the "Transformers", will be naming our team room "Cybertron", and have even assigned character names to members of the team. As the architecture groupie I am referred to as "Ironhide", weapons specialist, and one of Optimus Prime’s oldest friends.
Last week Optimus (our team lead) put together a great road map for what we’re doing and we will be distributing that around the company shortly. The road map identifies the key things we need to do starting from the foundation and building up to the bells & whistles we want in our applications. This road map has really become key to what we’re looking to achieve and is guiding us toward our short-term goal of a high-level plan and the associated deliverables.
Security is one of the foundations that is almost number one or at least shares number one with a few other things. After our initial meetings the security umbrella fell to me with heavy involvement from our security guru and other members of the team. We had designed several security solutions in the past and all of those were reviewed and compared to today’s standards which is where we arrived at our first recommendation. This level of work is interesting because it is tempting to want to dive into details, and that’s OK, but you also have to stay high level enough that you aren’t over-designing things from the start. The recommendation made revolved around the use of SAML and WS-Trust and a Security Token Service. Based on our research and experience this was our best "guess" as to what would be appropriate.
Part of this process also involves identifying vendors and products that may fit into some of our high level ideas. We found one vendor who was open enough to have an early dialog with us even though some of our timelines could put us out years and not just months. While their product definitely is very much what we’re looking for we were also looking for some validation that our best guess had some real merit. And this is my key point. The people on this team are very smart and have experienced a lot of things but we know we can’t solve it all and we can’t code it all.
We do know enough to take the business need, merge that with the technology experience, and create our best guess at a solution. Having that validated by what others are doing is critical. In the end, you and your business owners will know what is the best solution in terms of cost and maintainability. Looking to the industry for those best practices and ideas will help you create a solution that gives you the right balance and flexibility you need. You don’t have to have all the answers, but it never hurts to have good places to start looking.
Where do I look when I’m trying to find best practices and guidance to make sure I’m on the right path?
- Friends like Clint Edmonson, Architect Evangelist at Microsoft, Coworkers like Dave and others (who remain blogless)
- Area events such as ArcReady and .NET User Group Meetings
- My favorite blogs and my Delicious.com Bookmarks
- Standards organizations such as OASIS and W3C
- Search engines: Google and Windows Live Search. Try searches such as "Exception handling best practices .Net", etc.
- Vendors who have solutions for the problem I’m trying to solve (Usually found via Google)
The Calm Before: New Role, New Challenge
Jan 18th
I have been quiet the last few weeks though I have been meaning to post a few things. Since the beginning of 2009 I have been working to get several people on my team up-to-speed on Windows Communication Foundation and service oriented design which has proven to be no easy task. Condensing two years of study and experience into short lessons has been difficult because there is no cookie cutter mold that you can hand someone so they can bake up some services. Services take thought and consideration, planning, and careful implementation. Giving someone a template to start from is helpful, but without understanding why the template is set up the way it is much of that experience and knowledge is lost. I think this is largely a fault of my own because of the rushed feeling I have to get this knowledge transfer going into 2009.
On Friday the general manager of REJIS announced something that I think most people saw coming; the beginning of our technology migration plan to move from a Mainframe environment into a Windows based environment. As he outlined it at a very high level we see the picture of a multi-year company-wide effort to make this happen. This is a major shift for REJIS because we are known for our ?green screens? and our core competencies lie in the processes that are running on our mainframe systems. REJIS will be redefining itself as it moves in a new direction to offer new products and services to customers.
Just prior to the announcement I learned the role I would play in this new endeavor. I will be working on the small team that will design the overall architecture as the lead architect. The team is currently comprised of three people including myself. One is a Senior.NET developer and the other comes from the mainframe side though she has spent her more recent time studying .NET and assisting with project designs and documentation. We will be working directly with our IT Director and probably every division of the company as this affects REJIS all the way from the top down.
To say that the coming months and years will be easy would be a gross understatement. We will be converting a collective hundreds of years of peoples work to a new platform. Some of my closest colleagues have literally spent their entire careers building these systems. To call it a conversion is a bit misleading as well. What is being converted is that knowledge and experience in the industry we serve and in that conversion will be a redefining of REJIS into a more agile company ready to handle the changes the future will bring.
For me this is the best opportunity I could be called for. Over the last few years I have been one of several voices calling for better attention to architecture and design on our new systems and for constant attention to how new technologies will affect what we can do and how quickly we can do it. Now will be my opportunity to make REJIS a little bit better and to prepare our IT systems for a future that will allow them to grow, scale, and change in the demanding environment we work in.
I press forward humbled that I will play such a big role in this change and looking to peers and colleagues for their support and advice. People like David who never cease to amaze with their forward thinking, Clint and Denny who make their mark evangelizing the need for architecture and providing sound advice and wisdom from their experience, and my other (blogless) colleagues at REJIS who go along with my crazy ideas and add a little crazy of their own.
The next few weeks will involve a lot of groundwork, some travel, and time to reflect on the road ahead. It will be long and trying and for those of you who subscribe to my feed you will have a front row seat to the transformation that will happen.
Leadership Lessons From The Ranger Handbook
Nov 24th
I have not written about leadership in a little bit so I thought I would post this one. Studying leadership can take you to all sorts of places where leadership happens each and every day. There is probably no other place that leadership has the most visible and known impacts than in the United States military. Each branch of the military has its own unique leadership program that teaches core values and skills for leaders. Many of these leaders are tested in combat where the results are life or death for the leader and the led.
The leadership lessons taught by the military are simply stated in the most understandable manner possible. A great place to find solid leadership advice is Chapter 1 of SH 21-76, The Ranger Handbook. The bullet points tie into FM 22-100 the Army’s 283 page leadership handbook. SH 21-76 does a very good job of fitting these principles to a nice printable page.
From Chapter 1 of the Ranger Handbook, some of the most applicable leadership advice I have found in my studies.
BE
- Technically and tactically proficient
- Able to accomplish to standard all tasks required for the wartime mission.
- Courageous, committed, and candid.
- A leader with integrity.
KNOW
- The four major factors of leadership and how they affect each other are–
- Led
- Leader
- Situation
- Communications
- Yourself, and the strengths and weaknesses in your character, knowledge, and skills. Seek continual self-improvement, that is, develop your strengths and work to overcome your weaknesses.
- Your Rangers, and look out for their well-being by training them for the rigors of combat, taking care of their physical and safety needs, and disciplining and rewarding them.
DO
- Seek responsibility and take responsibility for your actions; exercise initiative; demonstrate resourcefulness; and take advantage of opportunities on the battlefield that will lead to you to victory; accept fair criticism, and take corrective actions for your mistakes.
- Assess situations rapidly, make sound and timely decisions, gather essential information, announce decisions in time for Rangers to react, and consider the short- and long-term effects of your decision.
- Set the example by serving as a role model for your Rangers. Set high but attainable standards; be willing do what you require of your Rangers; and share dangers and hardships with them.
- Keep your subordinates informed to help them make decisions and execute plans within your intent, encourage initiative, improve teamwork, and enhance morale.
- Develop a sense of responsibility in subordinates by teaching, challenging, and developing them. Delegate to show you trust them. This makes them want more responsibility.
- Ensure the Rangers understand the task; supervise them, and ensure they accomplish it. Rangers need to know what you expect: when and what you want them to do, and to what standard.
- Build the team by training and cross-training your Rangers until they are confident in their technical and tactical abilities. Develop a team spirit that motivates them to go willingly and confidently into combat. Know your unit’s capabilities and limitations, and employ them accordingly.
Simple lessons with direct application to all fields where leadership is needed. Over the next several weeks as I have time I will take each bullet and provide some simple examples of how each one of these principles can be applied in the day-to-day world of the architect as a leader.
First Certification for 2008
Nov 18th
School was never really my favorite activity so the idea of taking tests and getting certifications wasn’t totally appealing although I think in these days they are definitely necessary.
Three of my fellow co-workers and myself attended two days of sessions for the Justice Information Exchange Model (JIEM) certification. The methodology and tool were not difficult to learn and the exam was a little tricky; not hard, just a little tricky. It is definitely exciting to have some extra credentials especially as it applies directly to work I do everyday.
A big benefit of sending four of us is that we’ve all been exposed to this same methodology and tool which brings new perspective on how to apply it.
Congratulations to the three (if you had blogs I’d link you…) who passed!
A Lesson in Shedding
Oct 23rd
When you lead from the front you often have to be the jack of all trades. You got there because you were the best you could be at all the other jobs that make up what you do. Your coworkers come to you for guidance. Managers look to you for your opinion. You end up going to meetings one and two levels above your pay grade. Most of the time tackling tasks yourself seems faster than explaining it to someone and setting them on their way (which would require you to monitor their progress as well).
All this adds up to you not getting the real work done. You spend your days filtering questions, going to meetings, and tackling issues you shouldn’t be worried about; all the while your to-do list grows and nothing is being crossed off.
This is when it’s time to let go. Time to shed. Shedding will likely involve delegating something you really wanted to work on but you have to be honest with yourself: It’s just not possible to do it all. It may also involve casting something off as unimportant. Both are tough calls to make but in the end it will be necessary.
Forget about those things that are truly marginal. Do the stuff that only you can do and can do best. Let someone else do something that you don’t have time to be doing. They might be good at it too.
This Year is Just Practice…Next Year is for Real
Sep 8th
Back in January I made a crucial mistake. I asked for work. I asked for a lot of work. I didn’t get it in January but eventually I did. Last week it looked like my random vacation week was about to get canceled; fortunately it did not. I’m now sitting in my pajamas while my wife is rocking out with Guitar Hero III and I’m trying to get back some of the energy I had when I asked for all that work.
I have a lot of energy and I’m willing to devote it to my employer and to go above and beyond what is necessary. I do that when I have that energy available and when I believe what we are doing is the "right" thing. Apparently I’m not alone in this. Discretionary Energy is a hot topic in leadership and organizational development.
Not that it’s anything new. Militaries have used this throughout history. How else could you get someone to go to their potential death for little or no pay and without other methods of coercion?
Last week we had a reconnect session with the RLF and LLF graduates at REJIS. Dick Dooley was there and we got about an hour worth of verbal ‘beating’ from him (more like gentle reminders of the things we need to be doing). We talked a lot about discretionary energy because every organization needs it and needs its employees to devote some level of it to get the real work done.
The title of this post comes from one of Dick’s sayings which really clicked with me. I think it’s very true and has real meaning to all of us.
Keep practicing hard because the real work happens next year and it won’t be any easier.
Transformation: Keeping Up With Constant Change
Aug 10th
I was in a meeting last week where some individuals had very real concerns. Their job has been relatively the same for the last 10-15 years and with changes all around our organization they are truly wondering where their future lies in the organization. As I listened to their concern it really hit me that this uncertainty travels to work with people all across the country and the world each day. These individuals are afraid that the knowledge they have acquired over their career is now irrelevant and they were questioning, I think, if it is even possible for them to change and to learn something new.
My IT career started about 12 years ago. Since then I have been through probably a half-dozen or more programming languages, operating systems, vendors, form factors, you name it. The only thing that has ever been stable in my IT career is that some people love computers and some don’t. That and change. I have never been part of a change exempt IT environment and really wonder if one does exist. I know that what I learn today is nearly irrelevant tomorrow. The question is, how do you deal with that?
Early on in my tenure at REJIS it was easy to accuse me of jumping on the new hot technology bandwagon. I did run with a few of them but in the end I have been a little more conservative when it comes to implementing. I did not quit following those bleeding edge things because sooner or later they are relevant, even if for a short time. Microsoft has an entire division devoted to this stuff and Microsoft itself are the ones driving some of the changes their own people get paid to keep up with.
I believe in order to deal with change we must constantly be changing ourselves. What we know, what we think we know, even things we don’t even know that we know. All of it has to be changing a little at a time in order to stay relevant. And I’m not talking just about our skills or those tangible things that enable us in our trade. At the core of who you are you should be challenging yourself each day to be sure of who you are and where you are going. If this isn’t happening then one day the big change comes; maybe you saw it, maybe you didn’t, but either way you will be asking yourself the question: Am I ready to or is it time to do something else?
I am empathetic to those colleagues and I am hopeful someone can find new ways for them to move to another level and remain with the organization. Ultimately the choice will be theirs.
This was also my reminder to keep from getting comfortable. The only comfort we should have is to be comfortable being uncomfortable. Anything else and we’re not on our toes making little changes to survive the big one. It’s happening all around us and one day it will happen to you. The real question is, what are you doing about it?
Technorati Tags: Change,Transformation
The Architect and the Balancing Act
Jul 21st
I’m going to depart some from what I have been posting and touch on a topic that will get a little technical because it involves technical things. Read on even if you are a non-technical kind of person; I promise there will not be any code.
A big part of what I specialize in is distributed systems design and getting computer systems to talk nice with one another. As a whole the IT industry has been doing this for a very long time so nothing I do is inherently new or revolutionary. But the way we do it has evolved over time and we’re now in a paradigm which, I think, captures the essence of what computers systems really should do: represent the ‘real’ world processes we are automating.
Because I’ve made a niche for myself in this arena my boss delegates a lot of data sharing projects to me, if at least to review and make recommendations on what approaches we could take. In the Justice and law enforcement domain data sharing is the hot topic since 9/11 and believe me when I say a lot of data is finally being shared. This year alone I think I’ve reviewed around 15 new interfaces and we are implementing about a dozen.
I am currently the lead on four interfaces that will be created to share data with an external vendor for a system migration that is happening for one of our clients. Originally the interfaces were planned with some of our legacy integration patterns but we have since chosen to implement them in newer technologies that will have a longer sustainable life. Our team in particular has a lot of systems tied to our mainframe which limits our methods of interfacing with other systems and long term will cause an issue because most schools aren’t teaching COBOL as a mainstay of their MIS or CS programs.
I like to look at the future as well and keep those things in mind as we go forward sharing our data and enabling new interfaces. As I said, nothing I suggest is inherently new or revolutionary, but hopefully it is sustainable and represents the real world processes in a meaningful way to all the partners in the project.
The four interfaces I have been assigned were four that we had identified as candidates for a Service Oriented Architecture approach using web services or another service such as a queue. Due to resource constraints we were not going to work on these for some time; until this migration came up. Because a client needs this immediately we will be able to shift resources to make it happen. This is where the balancing act begins.
We are integrating with a vendor that we have not worked with yet. Most of my experience with external vendors has either been with the Department of Justice (which is going really well) or with a few other local vendors, one who’s idea of a project plan consisted of "Just send us what you have and we’ll take care of it" (80 work hours later they finally sent us their data element requirements). My organization has a lot of experience doing integration and as such we can be seem like a big contract driven beast, but that is from a lot of experiences where the plan resembles "send us what you got" and ends up in huge disputes and a round or two of the blame game.
In our final proposals to the client and vendor we changed our approach to use web services. A decision that myself and a senior staff member (as in 44 years with the organization) agreed would be best long term, even though he doesn’t speak XML or web services, he understood why we would want to use that approach. I believe this to be the best choice we can make given all the other variables.
What is beginning to happen now is the inevitable interface creep. Because every computer system has certain idiosyncrasies in how it works with data or represents those processes things get really fun when you start connecting two systems, especially when the domains you work in already have a history of differences i.e., courts and law enforcement agencies.
Many of the legacy interfaces I see were developed for specific purposes and for specific systems. Which really is fine because they get the job done. System A shares it data to System B and everyone is happy. But then system C comes along and it has different idiosyncrasies from System B and so System C demands that System A accommodate for those. The result: Someone copies the code from System A and modifies it to share data with System C thus resulting in two interfaces which share the same strengths and flaws. And someone has to maintain those. Indefinitely.
I want to prevent the situation above with Systems A,B, and C from starting at all. How will I do that? System A will expose a consistent abstraction of it’s data with a standard contract that is unchanging. The data will be shared in a meaningful way that, hopefully, will accurately reflect the most common business processes that system performs.
That last sentence is key to this whole balance act. It is your job as the architect to ensure that your systems interface accurately reflects the processes at a high enough level of abstraction that it is useful to any external parties even with all the little idiosyncrasies their system and your system has.
Undoubtedly as this project goes on requests will be made like "How about you always send us X with this response for this operation and Z for this one?" This is where the architect has to mediate, protecting the integrity of the external interface while allowing the flexibility to support the needs of known and unknown third parties who need your data. It will be a delicate act and one that I will be walking once again over the next weeks and months.
I can’t prescribe a one size fits all approach because a lot of this is situational. Is it an existing vendor or partner who has worked with you? Then they most likely understand. What if it is a new partner? What if they have no way to speak to you using the same technologies (web services, what are those?).
As we continue this paradigm shift from one model of systems to the next these situations will continue to put architects in the middle of balancing the integrity and consistency of their own interfaces, growing those systems into the futures in a sustainable way, and all the while meeting contractual obligations.
If you joined technology to get away from these kinds of problems it might be time to find a new job!
New General Manager, New Style
Jul 14th
The new General Manager at REJIS started today. During our all employee meeting where we got to hear first hand from our new top leader he let us know that we would see him at least 2 times a week circulating amongst the cubes. Amidst many other things, like a specialty in organizational change, I thought this was pretty interesting.
I have never served under an executive leader who follows management by walking around (MBWA) so this will be a new experience. Hopefully it leads to some good interactions and helps all the employees adjust to a new executive. I'll also be interested to see if this leads to a better feeling of transparency. One thing I notice there (and I think this is true of many organizations) is that it is very easy for people to feel like there is some big thing they are not part of. In my two years that has never been the case.
Another practice we'll see with our new GM is similar to what our IT director does: regular meetings with selected groups where any question or discussion goes. In the past this included questions as direct as "What if you don't get the GM position?" (which our IT director didn't; our new GM is a complete outsider to the organization, none of the internal candidates were selected) and "Can we get better hardware for developers?" The last question has resulted in trials with dual monitors as well as 22-inch wide screens. As the budget allows developers will get upgrades based on their preference. Its not everything we asked for but I think it's a great start!
Having survived executive leadership changes at my previous employer I have been through the turmoil and fear that arises. After meeting our new GM I am hopeful for things to come and will work on keeping a positive outlook and, as always, trying to be less easily bothered.
IT Leadership: From the front lines
Jul 14th
I decided to change the tag line today. This is probably not a big change but I gave it more thought after a working lunch with Clint Edmonson. I met with Clint today to discuss some very non-trivial matters of architecture and design related to a few projects I am working on. On the way back to the office we started talking blogs and he really encouraged me to put some more out here because leadership in IT and soft skills are not discussed enough.
When I first started to blog I was inclined to do a purely technical blog. The fact of the matter is there are literally dozens, probably hundreds, of really good blogs that cover that already. I wanted to find a focus on something unique and something not everyone is covering.
Don't confuse the 'front lines' with those serving on the true front lines in our current wars. The front lines I speak of are the ones you go to everyday. Perhaps your a development manager, or an architect, or even just a developer. No matter where you are you have a chance to lead or to follow (sometimes following can be leading). Sometimes both.
By title I have no management or leadership authority. Through delegation and the fact that I like to be a take charge kind of guy I have been granted some. What I'm learning is that there are many ways to lead and to be a leader.
For those of you on the front lines, cranking out code, designing distributed systems, and providing 24/7 support you are in the unique position to provide leadership and followership that your organization needs to thrive. In every good battle there are people who keep the troops motivated when the officers aren't around. Maybe you're 'that guy' or you want to be. Either way, stick around and let's start the conversation.
