IASA Infrastructure Architecture course coming in September…

23 04 2014

http://docandersen.podbean.com
http://docandersen.wordpress.com
http://scottoandersen.wordpress.com
My Amazon author page!!!!
http://www.safegov.org

If anyone is interested IASA is offering the Infrastructure Architecture course in September.

9/9/2014 6:30:00 PM
Infrastructure Architecture: Online Instructor Led (Virtual)
https://www.iasaglobal.org/assnfe/ev.asp?MODE=&ID=605

I have argued for many years that the overall concepts of infrastructure architecture evolve and change rapidly/ Much more rapidly than solution architecture. The reality of infrastructure architecture is as much that solutions move into the infrastructure and are absorbed by the IA team as it is the evolution and growth of security requirements.

Security is the job of every IT professional. From those who watch the edges of the network, to those who operate the solutions every day it is a critical component. Design for security, build for security and in the end deploy and operate for security.

Infrastructure Architects (IA) in the end are all about standards. Sometimes, by the way far to much about standards and not enough about innovation but that is for another time. Over time IA’s focus on mapping the right infrastructure for the now, and capacity so that the tomorrow won’t swamp the system.

Where cloud solutions can reduce the overall impact of a solution it does change how the IA looks at the environment. I’ve said for years that networks have been built from the core to the edges with the goal of providing core services to the edges. With Cloud that is reversed where core services are outside the network and you connect to them via your WAN. But the WAN was often designed outbound in not inbound and outbound.

That is the stuff IA’s deal with all the time. They worry about the total capacity of their network and when will the Ipv4 addresses run out? They are concerned about the impact of the solution on the network and the required security settings. They ask questions like what ports are you requiring be open on our firewalls? How do we update this new solution? What is required on the desktop for our users to be effective?

Sometimes its as if the Solution Architect and the Infrastructure Architect are speaking a different language. Add in an Enterprise Architect who may be focused on building/delivering solutions for the entire enterprise and it makes for an interesting conversation.

Keeping up your end (if you’re an IA) is a huge part of the IASA class. Its not what you know – but how you convey it to other people that makes for successful projects.

.doc

Scott Andersen

IASA Fellow.





New Communication issue…

22 04 2014

http://docandersen.podbean.com
http://docandersen.wordpress.com
http://scottoandersen.wordpress.com
My Amazon author page!!!!
http://www.safegov.org

I have a new issue that I would like to throw out to my readers. It’s a two part communication issue.

  1. If you don’t ask the question or ask for details how can you evaluate someone?
  2. If you don’t understand and you don’t ask questions in the end who is actually wrong there? What if what you believe (the world is flat) is in fact wrong?

In the end you lose out. The first points to the arrogance of the interviewer not the inability of the interviewed. It is, in the end, a very sad problem. I have been in interviews that were set-up to fail. If you have more than one person in the room interviewing only one person than unless it is a board format (and even then) you are setting up the interview to be a failure. The very reality of board based interviews is as much about rattling the interviewee as it is about finding information. Board based interviews require a moderator. Without a moderator there is no way the candidate can be anything but rattled.

The second problem is the scarier in the end. It happens in reality of the way things are or Brittle Culture of an organization. There is one right answer, and if the interviewee doesn’t give that answer in the end they are wrong. The way things are is the way things are. How would it be possible that there is a different way to solve the problem. So you have to ask questions. Asking questions by the way once the interviewee has gotten their initial why me piece out allows you to create a more collaborative environment. In a Brittle Organization however it doesn’t matter what you say, it’s the wrong answer or worse isn’t understood.

I had a team running interviews for new hires many years ago. Our first rule was not asked not evaluated. Not questioned, not evaluated. It forced the team to listen to the person being interviewed and in the end if they didn’t understand to ask questions. Otherwise you couldn’t evaluate the person.

There is an exception to the two rules of course. Many companies ask you to walk in knowing if you are hiring the person before you start questioning. In that case where you know the person is not getting a job – only the rules of courtesy apply. In that case its listening.

I love the old adage we have two ears and one mouth. I also like the even older adage about what sits between our two ears. If we don’t ask questions than in the end we hurt ourselves as an organization.

.doc

Scott Andersen

IASA Fellow.





Merging the old with the new…

21 04 2014

http://docandersen.podbean.com
http://docandersen.wordpress.com
http://scottoandersen.wordpress.com
My Amazon author page!!!!
http://www.safegov.org

In the distance…

Its been an interesting journey. When I started in IT the goal was get as much of the real world into the digital world. Scanners, hard drives, Wacom tablets and other devices were appearing. They were all expensive and you had to be careful how many you connected (as well as where you connected them etc.).

Ten Connections:

  1. MIDI
  2. SCSI
  3. E-sata
  4. IDE
  5. USB
  6. Bluetooth
  7. Wifi
  8. VGA
  9. DVI
  10. HDMI

There were many more (PCI, ISA and Microchannel) that we used and leveraged. Memory came in many different flavors. You had to be careful what you had connected to what you were using. SCSI was cool as a connector system because you could connect 7 (and later 14 devices) but like Token Ring things got flaky as you neared the maximum number of connections.

Add to that various connections we leveraged to input video or output video. I keep coming back to this concept of connections because of the change over the last five years in the space. What once was a balancing act now pretty much works. On occasion you plug something in that isn’t functional – but that is the less likely scenario now. Things are more likely to work than fail.

This changes of course how you operate. I talk about the concept of design for failure that was birthed from the reality of Brittle Computing. With this new reality there is less fear. I remember when I first got a copy of Windows 95. It was ground breaking and offered this new feature called Plug and Play. We called it Plug and Pray back then – why? Because the standards weren’t as tight and companies were learning what it meant to build drivers that wouldn’t freak the operating system out (or leave gaping security holes or worse).

I think a blending of the Brittle Reality and the new design for failure paradigm is called for. The way to achieve that is to focus on an operations framework. A way to  transition solutions into an enterprise fabric.

It’s a concept I’ve thought about for a long time. Organizational Tapestry represents a blending of both the Enterprise Architecture (what should be) and the Enterprise Reality (what is). From there we mix the new reality (design for failure) with the older realities (Brittle Computing) to create a cloud operational framework.

More to Come….

.doc

Scott Andersen

IASA Fellow.





A vision of tomorrow…

20 04 2014

http://docandersen.podbean.com
http://docandersen.wordpress.com
http://scottoandersen.wordpress.com
My Amazon author page!!!!
http://www.safegov.org

Simple.

Reduce overall complexity.

Make it easier to use.

Simple.

A rallying cry for technologists world wide. To build solutions that effectively are truly plug and play both cross platform but also cross device format.

Universal.

Java was supposed to be that unifying write once use everywhere platform but that isn’t in effect what Java has become. To many systems are bound to specific versions of Java or worse don’t operate the same on a Macintosh and a PC.

That quest for universal hit a snag with tablets. Android is a very interesting OS but Google needs to regulate it more. There are too many flavors of Android today and its too hard to manage. The simple reality of a poorly or differently enabled accelerometer can reduce the universal application to one flavor of Android on one device.

What is the path to simple?

First off I would like to bring full circle the concepts behind Brittle Computing. In looking at the overall move from compute to the organization itself there is the birth of the need for simple systems.

The other side of simple is the number of people using computer based solutions. In the 1990’s it was a dream (a computer in every house) in the 2000’s it moved to a computer, a smart phone and possibly a tablet in every house. What once took hours (moving video to the computer, can now be done with a simple plug and play copy).

Universal still lags – while there is a growing standards for video (putting it on YouTube and HD) its still a mix and match sharing video other than the one central location. Its better and improving to the point of being nearly universal.

Simple however shouldn’t be that difficult. I frequently use programs on a Macintosh and on a PC. In most cases I use very specific applications on each – but in the case of VM’s I use both Macintosh and PC. VMware workstation on the PC and VMware Fusion on the Macintosh.

Neither is hard to create VM’s for or import VM’s into. Both are pretty straight forward. It’s a little harder to move VM’s into Amazon or Rackspace from my VMware workstation, but its possible with conversion (and the same is true moving them out). Universal still lags here but like video its getting better.

Right now I suspect that proprietary is the largest blocker to simple. While You can as I said convert VM’s, it isn’t in the end easy. In fact it can be frustrating and time consuming. Plus each of the various cloud services has unique security settings you have to configure that make the overall process even harder.

In the end I think there will be a unifying path to simple. I just don’t think it is going to come from one of the existing players. I think the path to cloud deploy simple is going to come from one of the migration vendors.

The problems there are compatibility (none of the migration vendors work well together today). Eventually however they (the cloud migration vendors) will begin to work with a Cloud Broker to provide the true end to end simple cloud.

Its coming…

.doc

Scott Andersen

IASA Fellow.





One step towards not the way it has always been…

19 04 2014

http://docandersen.podbean.com
http://docandersen.wordpress.com
http://scottoandersen.wordpress.com
My Amazon author page!!!!
http://www.safegov.org

In the end you have to balance the good with the bad. Within all news is the kernel of reality you have to find. If you don’t find that kernel it is incredibly hard to move forward.

I found the kernel finally. It lies within what I want to do and what I was looking for. Now that I know what it is I can move forward without fear.

Yesterday I downloaded the newest version of the eBeam software. It’s a great tool for capturing whiteboard input and sharing it, either via email or during a live meeting. I find that standing up at a whiteboard helps me think. When I first started in consulting I drew timelines like I did as a teacher (vertically). The reason for a vertical timeline was so that you could go back and add additional information to any one section easily. Plus writing vertically allows you to easily turn to the left or right without impacting what you are doing, as well as create impact factors in timelines.

IT timelines are supposed to be horizontal. I used to get in trouble for that because I still think vertical timelines are in the end a better way to go. You can create a three column timeline easily impacts, timeline event, potential risks and changes. I do horizontal timelines now but I still think vertical ones are better.

The reality of the profession I’ve lived in is that change is not something IT adapts to easily. It comes from the Brittle Culture (the way things are is the way things are) and the manifestation of that culture in the way we do things.

Plus, people don’t always like change. Change = disruption and that isn’t optimal. People like consistency. It will be this way the next time I pick it up.

Its why really Brittle Orgs struggle with Cloud solutions. They hide behind the cloud security failings to say cloud isn’t secure. Once you convince them of that they argue that in the end the savings from cloud don’t apply to their organization and so on. It has in the end nothing to do with Cloud solutions rather the Brittle Organization.

At some point the Brittle Organizations are swept along in the great change. Moving from the backwaters to the eddy and then back into the current (for a time) before getting off and moving into the eddy and then backwater again.

Success at times is simply moving one step forward. Making things for one step not the way they always have been.

.doc

Scott Andersen

IASA Fellow.





My 3 rules for starting a project…

18 04 2014

http://docandersen.podbean.com
http://docandersen.wordpress.com
http://scottoandersen.wordpress.com
My Amazon author page!!!!
http://www.safegov.org

The largest frustration is always the one that stops you. It’s the same by the way, projects or personal. Whatever is frustrating the project is the one thing that slows or delays the project.

Many years ago I used to deliver MSF courses. MSF is the Microsoft Solutions Framework, a system built by both the MS Product groups and the MS Consulting service to show the what and how of projects within Microsoft.

There was a great quote that projects never slip 6 months in a day. They slip 6 months over the life of the project. The largest frustration of the team is often what causes the slippage.

Now a good architect will tell you that the reason a project slips has as much to do with the requirements as it does the vision. The old resource triangle bites again. That said I wonder about that.

What in the end is the cause of the frustration. I’ve spent years on this blog talking about the reality of communication (what is said, and what is heard). In fact the longer I work in the IT industry the more I realize that issue is the greatest impact on projects, period.

Sure there is the reality of technology that doesn’t exist yet. But that is a communication issue. If the requirements drive you to something that doesn’t exist and won’t exist for a time you need to evaluate what you are considering. I always tell architects I am working with the following rules (some of which came from a co-worker a long time ago, some of which I’ve modified from other things.)

  1. Rule number 1 is communicate. Communication is a two way process not a ONE WAY process. Make sure you speak clearly and that the person can listen. (the can is operative – many times people are so wrapped about being right or a specific idea that they cannot listen).
  2. Rule number 2 is determine what you need and make sure it is possible today. If you need something that doesn’t exist yet consider that very carefully. Its beyond the horizon for a reason. Make sure you can climb the wall before you place that wall on the critical path of your project.
  3. Rule number 3 failure is an option. Failure is also a teachable moment. If your company doesn’t revel in failure you are doomed to repeat the failures over and over. Jump into failure with both feet. Hire a school teacher to talk about why failure IS THE MOST IMPORTANT LEARNING TOOL ANYONE EVER HAD. Teachers watch where kids fail on purpose – not to critique but to improve. You can never get better if you don’t fail. Safety simply means you never take risks.

I have no idea how many mentees I’ve shared this with. I’ve refined it a number of times over the years so I doubt more than 2 or 3 actually got this message. But the meaning is the same even if the words are different.

.doc

Scott Andersen

IASA Fellow.





Themes of blog past…

17 04 2014

http://docandersen.podbean.com
http://docandersen.wordpress.com
http://scottoandersen.wordpress.com
My Amazon author page!!!!
http://www.safegov.org

Trivia question. How many lines have I typed as blog starters only to delete the line and start over. The sad thing about the question is I know it’s a lot, but I have no clue what the answer really is.

Moving a concept from what I am considering to my blog takes some time. Normally at least two cups of coffee and something that sparks my interest. I tend towards wandering the blogosphere to see what is out there. I seldom react to what is there now, but sometimes based on what I am reading I see a trend that hasn’t been called out and I try to move on that.

My series recently has been about the concepts of Brittle Computing. It has as much to do with the way companies approach computing today as it did during the heyday of Brittle Computing now more than 20 years ago. I also invested time and effort in creating a number of other blog topics that I have touched on a few times since creating them.

Blogs of the past:

  • The Cloud Whisperer – created as a response to the reality of cloud hype. What is cloud changes almost every day. The Cloud Whisperer was created by me to cut through the crap and get to the real answer.
  • I did a series on Windows phones and the fact that they were dying. My friends reminded me over and over via email that Windows Phone is increasing market share in some countries. It’s the same argument that Linux vendors used to use when comparing themselves to Windows Server (we grew 1000% this year). When you have four servers in a business and they add 36 more you’ve grown 1000% no question. But the reality of that argument is the law of large numbers. Once you get to the 39% mark its hard to have double digit handset sales growth.
  • The Syncverse – it turned into a book.
  • The Cloud Dating Game – after the Cloud Whisperer I was trying to find another way to put the reality of cloud into perspective. The hype and the reality just don’t sit well with me.

All of these wound around the broader theme of organizational dynamics and communication. I have been arguing the reality of organizational dynamics for many years. In fact I believe that reality is what destroys companies. The consumption of smart people and innovation to fuel the fire of corporate growth creates a competitive shark culture that feeds upon itself until it blows up.

I am sure I have a few new themes to dive into.

.doc

Scott Andersen

IASA Fellow.








Follow

Get every new post delivered to your Inbox.

Join 1,356 other followers