Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
Software Development Blogs: Programming, Software Testing, Agile Project Management
Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
Over the last decade, studies have shown that, despite the dominance of source code, sketches and diagrams play a major role in software engineering practice.
The focus of our current research is to expand our knowledge on the use of sketches and diagrams in software engineering practice. We are particularly interested in how these visual artifacts are related to source code. We do not exclusively focus on software developers, but on all "software practitioners" including testers, architects, project managers, but also researchers and consultants.
If you think that you belong to this group of software practitioners, please help us gaining deeper insights into your work practice by participating in our short survey. It just takes five to ten minutes of your valuable time:
For more information, don't hesitate to contact me.
Thanks in advance for your participation!
Back in March I spoke at QConLondon 2013 on the topic of "Modern Legacy Systems". The video, along with synchronised slides, is now available here. Having just re-watched it I am reminded that I need to work on my timings for presentations (to avoid being gesticulated at to hurry up).
This is especially the case as I'm giving an updated version at Skills Matter as an In The Brain talk. Hope to see you there!
If any of these items interest you there's a full description of each sponsor below. Please click to read more...
This is a guest post by Mark Bestauros on what heâs learned about Value Realization at Microsoft. You can think of Value Realization as simply the value extracted from a process or project. Mark is the Microsoft IT Principal Business Value Realization manager, and a member of the Microsoft IT Portfolio Management Team, where he is responsible for the optimization of a significant IT spend across the Microsoft businesses. Mark is also responsible for the Value Tracking for projects in scope, and that has led to some big breakthroughs in terms of reporting the value of IT investments back to the business, and demonstrating the power of Value Realization.
Iâve asked Mark to share some of his key insights and lessons learned from his adventures at Microsoft in the art and science of Value Realization.
Without further ado, here is Mark Bestauros on Value Realization âŠTwo Main Purposes of the Value Conversation
The Value conversation serves two main purposes in IT:
To accomplish the first goal, the organization need to have the Value conversation tied to the Personal Commitments for all those involved in IT work, and equally importantly, making sure that the a mutual understanding of priority positioning of the âValueâ focus in the Conditions of Satisfaction conversations that usually take place between IT organizations and the benefiting business partners from the IT effort.
Without having the Value activities reflected in the commitments and missing in IT native processes, almost all involved in project work automatically de-prioritize the Value work, starting with turning a blind eye on a missing business case analysis at the inception point and ending with walking away immediately after a project Pre-deployment sign off meeting, washing their hands from any commitment to measure and evaluate the actual benefits hoped for at the Envision or âPlanâ phase.Planning and Prioritizing with Value Experts at the Business and IT Borders
The key to success is to embed Value experts at the business and IT border checkpoints. You need Value experts who are well versed in understanding how to sell the Value argument. You also need professionals who can guide the average IT professional through estimating effectively (versus guestimating). You also need to embed the most cost effective, and time effective, means to measure baselines and project logical improvement deltas at the business and IT border checkpoints. This will help you facilitate effective Portfolio Planning and prioritize demand more effectively, prior to having the all up IT/Business Leadership Team Planning marathons.âTests for Successâ for Value Realization
Evidencing the argument about the viability of the IT organization in any company with actual Realized Value is very compelling only if the Value reported passes these tests:
There are few characteristics or knowledge areas that makes a value practitioner successful in changing the culture and move the Value Organizational Maturity in the right direction:
A value practitioner canât achieve that alone, while overcoming organizational undisciplined Value approaches if any exist at all, lacking individuals Value commitments and the unwillingness of the business customers to engage in meaningful Value (BCA, VRF or BVR efforts), he/she needs air cover and a value sponsors (usually are found in the Finance Community or if lucky, a CIO or a member of two of the senior leadership) to facilitate the conversation and help open the doors.Executing Value Realization
On the tactical and execution level the Value practitioner needs to:
The three technical challenges are primarily:
There are known techniques that address each, and there are some that I had to improvise to make them fit the maturity stage of the target organization. In all cases, getting stakeholder agreement to the assumptions, transferring functions, and using the Dollar as an IT solution provide horse power to go a long way.
Readers of High Scalability know are well versed in performance optimization techniques. Reverse proxies, Varnish, Redis — you hear about them daily. But what you may not realize is that one of the oldest technologies in your stack can be one of your biggest bottlenecks: DNS.
People don't spend a lot of time thinking about DNS. It's not sexy. It's an infrastructure service, and it's just supposed to work.
At BlueStripe, we work with many teams running applications that support millions of web requests a day. We keep seeing DNS delays and errors that the platform operations team never knows about. It's so common we've start calling it the Hidden DNS Tax.What is the Hidden DNS Tax?
Communicating your ideas and architecture work effectively can be really tough. When we do we using create compelling visuals or models to communicate the complexities of our work. When I talk to architects I find there are many out there that really struggle with getting their messages across to their customers. They also feel that sometimes their communication is just out of their control or the audience just doesnât get it. Meaning, they should get it, what were they thinking, right?
But is it really there fault? Maybe, maybe not.Â
The genesis of this post came from a series of recent conversations. I wasnât sure if I wanted to create this post or not given the topic but in the past two weeks I have wither run into scenarios or have been asked specifically about this topic. The questions were all different but all led to the same basic theme. These questions included:
For as long as I have been in IT I have seen this. The same debates but with different names continue on. For those that have either worked for me or know me I have had the same answer for some time now. But lets wait on that door a momentâŠ
Itâs a funny adaption to a very real situation. I often find my self in a modern day Capulet vs. Montague battle between which is the better way to describe the things we architect.
âWhat's in a model? That which we call a Business Capability Model,
By any other name would it be as effective to describe our businessâ
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - adapted from Act II, Scene II of Romeo and Juliet
There are a couple aspects to this scenario. The first is the tooling. I usually see three camps here. The EA tool folks that use it for modeling, the Visio folks and the PowerPoint folks. Then comes the real holy war, the actual notation. Some say itâs UML, some believe itâs ArchiMate while others just stick to their homegrown methods.
While sometimes interesting to watch, it can be frustrating to watch the debate. What it ultimately boils down to is, while we are having debates about which tool and notation the following isnât getting done:
I think we lost our perspective on why we create these rich visuals, models or diagrams. These serve two primary purposes in my mind:
You might say, well Mike, you forgot about all the rich things you can do in the modeling notions that can link aspects of your architecture together in a very qualitative way. I agree these are important and sometimes be game changing if you are at a level of maturity to support it. However, if the two primary aspects are not covered, what you modeled is shelf-ware. If your stakeholders who are paying for your effort canât buy-into your architecture just for the simple fact that they canât get their heads wrapped around our world of architecture, we have failed as architects.
A model being used as a communication tool, is the most important aspect in my opinion. This isnât just my opinion but that of the architectural standard for describing architecture, ISO/IEC/IEEE 42010:2011 or formally known as IEEE 1471. In this standard, there is a core problem we are solving (i.e., Mission) with a set of stakeholders that have concerns that need to be addressed. Those concerns are addressed through the architecture models (i.e., view points, views and models).
The problem we get into is we want our models to be perfect. This may mean a high order of fidelity in the models, highly detailed or have a high level of precision. The challenge here isnât perfection but that of communication to our stakeholders that have either sponsored (i.e., paid) for our efforts and/or need to buy-off on the architecture before it sees the light of day. Like the quote about truth, âthe right model is in the eye of the beholderâ or the Don Box quote, âAll models are wrong but some are usefulâ.
So if we agree with the assertion that the critical component of a model is used as a communication method to stakeholders of all different varieties, then letâs consider the following breakdown to not choose the one model to rule them all, but rather a set of fit-for-purpose models that apply to the appropriate audience along with the right situation.
I break the models we create as architects up into two categories and add an additional one as the supplemental repository for ad-hoc models that fit only special circumstances.
Below is a visual that describes this as well:
The reason we want to break these up this way is simple, one set of models you use to communicate directly with your stakeholders or as I labeled them consumers of the models to be a bit more generic. These people who view these models do not have the architectural skills you do nor do they understand the complexities that go into our job. More times than not, it can be determinate to try to educate on the architectural detail as they donât have the understanding or the experience to fully understand why the decisions were made.
On the other side you have models for architecture professionals. These people are very knowledgeable in the architecture space. More times than not, they are looking for detailed models with a high degree of rigor to understand the impacts the architecture may pose. I have also referred to these people as the âBuilder Guildâ.
Why call them that? Itâs simple really. Just like in other well established profession you will find that the practitioners very different when among their own professionals versus in front of their customers. A great example of this is with home builders. I have built several homes and have had the same experience. I never got a blueprint. I only received a layout with dimensions and maybe a 3D video. Outside that I wasnât provided anything else. The builder gave me as much as I needed to make a purchase decision with that model and others.
When we reflect back to the problem at hand I would strongly suggest we treat the way we communicate along with the visuals we provide just like how many other very mature professions treat it. If we do that, I think we will be much more effective in our success with our customers.
Mapping back to the structure defined you will see some interesting responses to the questions that were asked.
#1 What architecture modeling language should we use?
It just depends on who you are talking to. A consumer vs. an architecture professional. For an architect perhaps you want to use an industry standard notation like ArchiMate. However if you are talking to one or more people from across your organization like a business unit executive perhaps you want to throw out all those complexities and go straight to either existing visuals that have worked well or build less structured visuals with styles that he/she is accustom to.Â Â
#2 Should we be using ArchiMate notations instead of BPMN and UML?
If we build on the first question and assume this question is geared for an architecture or IT audience then it would be the right question to ask. Keep in mind all of these notations are tools in your virtual EA toolbox. Each one of these notations has a role and caters to a specific audience. Each one of these has a discrete audience and purpose. ArchiMate for architecture, UML geared for software development and BMPN built from UML to describe business process more effectively. My advise, donât try to use one for everything, make sure what you build is fit for the task at hand.
#3 PowerPoint isnât for architects, Visio or [EA Tool Name Here] is.Â
I heard this statement more than a few times, with some more negative in tone. My belief here is all three classes of tools are appropriate for the right situation.Â The tool that seems to get picked on the most is PowerPoint. In my own experiences or have seen / witnessed, there have been very clear successes with using a tool like PowerPoint. Remember, itâs not the tool or the notation, itâs the circumstances and the audience in which you are addressing.Â
So the final words of wisdom, donât get caught up in the architecture modeling debate. Itâs just a model, get over it. Reverse engineer from what the expectations are from your stakeholders.
If you donât know the scenarios for the Cloud, itâs hard to make the case for the Cloud. Whether youâre a Solution Architect, Enterprise Architect, Business Leaders, IT Leaders, CIO, analyst, etc., you need to know the pains, needs, and desired outcomes so that you can rationalize the technology more effectively.
What youâll find below are collections of scenarios large and small that will help you see the full landscape of the Cloud within the Enterprise landscape. When you have the scenarios at your fingertips, you can better evaluate business strategies or technical strategies, as well as create more effective business cases, because you understand the pains, needs, desired outcomes, as well as the benefits that go along with each scenario.
Business and IT Scenarios for the Cloud
Category Scenarios Business Scenarios
Achieve cost-effective business continuity
Create new revenue streams from existing capabilities
Decrease power consumption
Decrease the time to market for new capabilities
Easily integrate new businesses into your organization
Improve operational efficiency to enable more innovation
Improve the connection with your customers
Provide elastic capacity to meet business demand
Provide Enterprise messaging from anywhere
Reduce upfront investment in new initiatives
Consumerization of IT
Corporate Environmental Sustainability
Innovation for Growth
Low-Cost Computing in the Enterprise
For details on each of the scenarios, including a description and key benefits, see:
Cloud User Stories for Business Leaders, IT Leaders, and Enterprise Architects
Here is a robust collection of User Stories for Cloud Enterprise Strategy.
To do a deep dive on the pains, needs, and desired outcomes from around the world, I created a round up of user stories for the Cloud, from the perspective of business leaders, IT leaders, and Enterprise Architects. I included many CIOs from several large companies in different industries to get a broad perspective. I ended up with more than 50 user stories of the pains, needs, and desired outcomes for the Cloud in the Enterprise. Note that while the list is a bit dated, many of the core user stories are still highly relevant and actually evergreen.
With a prioritized list of the user stories for the Cloud, I then grouped them into a simple set of categories:
If you havenât seen it, TechNet has a Cloud Scenarios Hub.
I like the focus on scenarios â itâs a great way to bring together a problem and a solution in context, while pulling together all the relevant guidance. Itâs a focusing anchor-point in action.
I created a simple index to the Public and Private Cloud Scenarios.Key Links
“No one can whistle a symphony. It takes a whole orchestra.” — H.E. Luccock
Welcome to my roundup of blog posts from across Microsoft on the art and science of Program Management.
The Program Manager role is a very powerful one. I think of it as a technical entrepreneur that blends customer focus, with technical skills, and business acumen. It’s the blending of those three domains that makes it so powerful for bringing ideas to life.
Great PMs make things happen by setting a vision, bringing a team together, creating an execution engine, and shipping ideas that change the world.
What exactly is a Program Manager? At Microsoft it’s a role that means many things to many people. In general though, when you meet a PM at Microsoft, you expect somebody who has vision, can drive a project to completion, can manage scope and resources, coordinate work across a team, bridge the customer, the business, and the technology, act as a customer champ, and influence without authority. From a metaphor standpoint, they are often the hub to the spokes, they drive ideas to done, they take the ball and run with it, or find out who should run with the ball. Some PMs are better at thought leadership, some are better at people leadership, and the best are great at both.
One of my favorite quotes that helps distinguish program management vs. project management is by G. Reiss:
“Project management is like juggling three balls – time, cost and quality. Program management is like a troupe of circus performers standing in a circle, each juggling-three balls and swapping balls from time to time.”
“The winners in life think constantly in terms of I can, I will, and I am. Losers, on the other hand, concentrate their waking thoughts on what they should have or would have done, or what they can’t do.” – Dennis Waitley
One of the ways I set better goals and achieve them at Microsoft is by using well-defined outcomes. It’s a way to begin with the end in mind. An outcome is simply something that follows as a result or consequence.
Maybe the best way to think of an outcome is that it answers the question: “What do you want?”
(If you want to just jump to the recipe and full expanded explanation of how to set better goals, go here: How To Set Better Goals with Well-Defined Outcomes)Outcomes are the Key to High-Performance and Outstanding Results in Work and Life
NLP (Neuro-Linguistic Programming) has popularized the use of outcomes over the years to help people achieve better results. You can think of NLP as a way to model excellence and replicate it from one person to another. It’s a way to program your mind, body, and emotions using advanced skills for high-performance. (Tip – if you don’t’ program yourself, somebody else will.)
Imagine if you could model what the most successful people think, feel, and do, and get that on your side.
If you like languages or the idea of language to share and express concepts, you’ll especially appreciate the power of NLP. NLP helps you create a lot of precision in how you see things, how you articulate things, how you filter information, and how you distill feedback into actionable insights.NLP is for Continuous Learning, Agile Personal Development, and Business Results
NLP is like Agile Personal Development where continuous learning is fundamental to its core.
NLP is probably the most powerful set of techniques I’ve ever come across for personal development, personal effectiveness, leadership, and high-performance. The techniques effectively help you find better, faster, easier ways to accomplish outstanding results, while helping you bring out your best. Tony Robbins popularized NLP back in the 80’s, but it’s more mainstream today.
In fact, I know a lot of executives and highly effective Softies that use NLP to get the edge in work and life. I also know a lot of developers that have NLP under their belt and it helps them clarify what they want, set better goals, take more effective action, and communicate more effectively to themselves and others. In fact, some say that NLP is simply a set of advanced communication techniques.Developers Love NLP When They Stumble Upon It
Developers often find a special place in their hearts for NLP because of its precision and how it helps to “codify” behaviors. Specialists often use NLP to model high-performance behaviors and break them down into a recipe. These recipes for results help guide your thoughts, feelings, and actions in a more powerful way.
Anyway, what makes NLP powerful when you are setting goals is that it helps you really identify the end in mind. It brings your full senses to bear, so instead of imagining a fuzzy scene of what success looks like with loosey-goosey language, it forces you to get specific and use precision, and to really get clarity on what you actually want to achieve.
After all, it’s a lot easier to get to where you are going, if you know what you really want to accomplish.
In addition to helping you create compelling scenes of success, or mental movies of your future victories, NLP also helps you break your goal down into actionable chunks. It also sets you up for success by teaching you to focus on feedback as a way to improve, not a sign of failure. In this way, you keep refining your actions and your outcome until you achieve your goal.Patterns and Practices for High-Performance and Personal Development
What most people don’t know about NLP is that it’s been an effective tool for years for building a great big body of knowledge around high-performance patterns for individuals, teams, and leaders. The NLP framework provides a way to capture and share very detailed patterns of behavior that help people improve their performance. Whether you want to improve your leadership skills, or your relationship skills, or whatever, there is a bountiful catalog of very specific patterns that help you do that.
And, the beauty of patterns in NLP is that they tend to be very prescriptive, very specific, and easy to follow and try out. This makes it easy to test and adapt until you find what works for you. (I’m a fan of don’t take things at face value – test them for yourself and judge from results. I’m also a fan of Bruce Lee’s timeless wisdom: “Absorb what is useful, Discard what is not, Add what is uniquely your own.")
One of the best books I’ve found is the book, The Big Book of NLP Techniques, by Shlomo Vakni. Surprisingly, it actually delivers what it says on the cover. There’s more than 350 patterns at your fingertips. I wrote about one of the patterns, Well-Defined Outcomes, in my post on How To Set Better Goals with Well-Defined Outcomes. You need to see it to believe it. It really is detailed, so if you’ve ever struggled with setting goals, this might be your big breakthrough.The Big Breakthrough in Goal Setting
Here’s the real breakthrough though in goal setting. Aside from making sure you have goals that inspire you, and that they are aligned with what you really want, the power of the goal is ultimately in moving you in the right direction. It’s not a perfect or precise path where you can simply do A and get B. In fact, the irony is, that if you really want B, your best strategy is to first act as if you already have B. This will help you think, feel, and act from a more effective perspective so that your actions come from the right place, and help you produce more effective results (or at least guide you in the right direction).
That’s why you often here people say that you have to BE-DO-HAVE, not HAVE-DO-BE. With HAVE-DO-BE, the idea is when you get what you want, then you’ll start doing the things that go with it, and finally you’ll act the part. This is like saying that you won’t show up like a leader or act like a leader until somebody appoints you in a leadership role. This creates a negative loop, since why should anybody put you in a role that you don’t act the part.
The right thought pattern is BE-DO-HAVE because then your thoughts, feelings, and actions support your end results.
Are you acting like what you want?
If you’re not getting what you want, what does your feedback tell you to change?You Might Also Like
Hey, it's HighScalability time (this week is a fall harvest basket overflowing with good nutritious wisdom):
Don't miss all that the Internet has to say on Scalability, click below and become eventually consistent with all scalability knowledge...
Tom Preston-Werner, GitHub Cofounder, wrote Ten Lessons from GitHub’s First Year in 2008. Though the lessons are still relevant, and the war stories behind each lesson are great, I can't help but wonder what a 2013 version would look like?
âAnyone can hold the helm when the sea is calm.â â Publilius Syrus
Change is tough. Especially leading it.
Whether you are leading yourself, others, or organizations through a change, it helps to have tools on your side.
Recently, I read Leadership Transformed, by Dr. Peter Fuda.
It uses 7 metaphors to guide you through leadership transformation:
It might seem simple, but that's the point. Metaphors are easy to remember and easy to use.
For example, you can use the Movie metaphor to increase your self-awareness and reflection that allow you to first "edit" your performance, and then direct a "movie" that exemplifies your leadership vision.
The other benefit of simple metaphors is they allow both for creative interpretation and creative expression.
I appreciated the book the further I went along. In fact, what really clicked for me was the fact that I could easily remember the different metaphors and the big idea behind them. It was a nice brain-break from memorizing and internalizing a bunch of leadership frameworks, principles, and patterns.
Instead, itâs just a simple set of metaphors that remind us how to bring out our best during our leadership transformations.
The metaphors are actually well-chosen, and they really are helpful when you find yourself in scenarios where a different perspective or approach may help.
Even better, the author grounds his results in some very interesting data, and aligns it to proven practices for effective leadership.
Here is my book review: Book Review: Leadership Transformed: How Ordinary Managers Become Extraordinary Leaders
I included several highlights and âscenesâ from the book, so you can get a good taste of the book, movie trailer style.
If you end up reading the book, I encourage you to really dive into the background and the anatomy of the Leadership Impact tool that Dr. Fuda refers to. Itâs incredibly insightful in terms of leadership principles, patterns, and practices that are fairly universal and broadly applicable.
âIf you love life, donât waste time, for time is what life is made up of.â â Bruce Lee
Aaron Lynn and Thanh Pham of Asian Efficiency wrote a thoughtful and interesting post about why they like Agile Results over GTD:
Here's the opening blurb:
âHereâs a short, fun article about why I prefer JD Meierâs Agile Results as a foundational productivity system more than Getting Things Done (GTD). Not that GTD isnât awesome, it just misses a lot of things given the complexity of our lives nowadays. If youâve been on the edge about switching to Agile Results, here are 6 great reasons why.â
What I like is that they are fans of GTD and are familiar with both systems.
I used to get asked how Agile Results related to GTD. My most common response was âŠ âbetter togetherâ and âto each his ownâ or âabsorb what is usefulâ. Of course, Bruce Lee was an early influence on me: âAbsorb what is useful, Discard what is not, Add what is uniquely your own.â
That said, I never had a snappy unique selling proposition, other than Agile Results is a personal results system for work and life. For many folks, they liked when I said that itâs a âsimple system for meaningful results.â For other folks, they said the big deal is âoutcomes not activities.â
I actually think thatâs the key: meaningful results.
A lot of Agile Results was born out of a desire to achieve 3 key things for as many people as I could:
On #3, I always think of the line from Rocky 6:
âNobody is gonna hit as hard as life, but it ainât how hard you can hit. Itâs how hard you can get hit and keep moving forward. Itâs how much you can take, and keep moving forward. Thatâs how winningâs done.â â Rock Balboa (Sylvester Stallone)
I also think about my last visit to one of the Block Busters that was closing. The lady there had spent the last several years of her life. For her, Block Buster was her life. With Block Buster closing, she didnât know what was next. She was scared. She was feeling the struggle of each day, and wondering how to keep going.
I confidently gave her a copy of my book, Getting Results the Agile Way. I was confident that it would help her figure out how to write her story forward. I was confident that she could use it to help her find her strength each day. I was confident that she could use it to help her figure out whatâs important in her life and spend more time on that.
In that instance, the last thing I wanted to do was to show her how she could use Agile Results to get more things done. Instead, I wanted Agile Results to help her get back on her feet again and bring out her best, and to help her write her story forward.
I wanted help her to hit her high notes.
And, I wanted her to have better endings, brighter beginnings, and better adventures along the way.
Ultimately, I wanted Dr. Seuss's timeless wisdom to ring true for her on multiple levels:
âDonât cry because itâs over, smile because it happened.â
I hope with Agile Results, I help people smile more.
As software developers, we value abstraction. The simpler the API, the more attractive it becomes. Arguably, MongoDB’s greatest strengths are its elegant API and its agility, which let developers simply code.
But when MongoDB runs into scalability problems on big data, developers need to peek underneath the covers to understand the underlying issues and how to fix them. Without understanding, one may end up with an inefficient solution that costs time and money. For example, one may shard prematurely, increasing hardware and management costs, when a simpler replication setup would do. Or, one may increase the size of a replica set when upgrading to SSDs would suffice.
This article shows how to reason about some big data scalability problems in an effort to find efficient solutions.
Defining the Issues
Wow, itâs been 2 months since my last post. I canât believe itâs been that long. Things have surely heated up this summer . Outside of spending some quality R&R with the family, I have been extremely busy in three areas:
As many of you know, I frequent EA conferences whenever I can make it happen. This summer being no exception.Â Over the past few months, Iâve talked to many of you and you have commented favorably on the content on my blog. I wanted to send a very public thank you. I am usually writing from direct experience or providing emerging thoughts based on those and itâs great to hear that resonates. Given that, over the next few weeks I will post up more content based on the questions and feedback from my presentations. This will also come with some extended materials that will provide more context into my thinking around those topics. As the year is coming to a close, the last two events major event of the year I will be going to for sure will be:
One of the best parts of my job is getting out of my office and into the thick of it with practicing EAâs. Iâve had an absolute blast talking with executives and EAâs about their challenges and how to enrich aspects that are working really well. Not only do I get to share my experiences but I am also learning a ton as well.
Outside of collaborating with practitioners and speaking at conferences Iâve been busy with standards work. I have, âput my money where my mouth isâ . A few months ago I posted the âCall to Actionâ for EAâs who want to make the profession better to contribute to the standard. So that is exactly what I am doing. I am taking my real world experiences and bringing it back into the standard.Â
As of the last member meeting at the Open Group conference I am directly leading or providing substantial focus and leadership in three areas:
If any of you out there has an interest in participating in these activities, please let me know via my Twitter handle @MikeJWalker. This is especially true if you are an internally facing company practicing EA. One of the key objectives of building the next wave of the standard is to ensure applicability to all of you and base on proven practices.
Sorry for the lack of âmeatyâ EA goodness in this post, but several of you out there have asked where I had gone and thought it would be good to give all of you an update on what Iâve been up to outside of blogging.
I canât say it enough, a big thank you to all of you that have stuck with me all these years reading my ramblings on blog(s), twitter comments and listening to my presentations. I canât thank you enough.
Every now and then I get some question by email, I usually just answer them directly but considering I got 2 such questions this week and that I have’t blogged for awhile (I do have a post about YARN which I hope to finish soon) – I thought I’d also publish my replies here.
Question #1 from Simon:
In your very interesting article “Bridging the Impedance Mismatch Between Business Intelligence and Service-Oriented Architecture” you highlight the challenges for BI and SOA to co-exist â that was 6 or so years ago â have you seen any advances that would cause you to revise that view?I think the gap and dissonance between SOA needs and BI needs is still there. However, in addition to event publishing mentioned in the article, I see the approach to getting to BI on SOA getting more standardized. I outlined that in my book under “Aggregated Reporting” pattern (aggregated-reporting/) where essentially you create an immutable storage of historic data and let different services each update thier part of the big picture. A trend that we see in the last couple of years, is the adoption of Hadoop (and other big-data platforms) as a means to implement the aggregated reporting pattern. The advantage of a platform like Hadoop is the ability to handle poly-structured data and apply schemas on read which help alleviate the challenges of diverse data sources that flow into the aggregated reporting pool
Question #2 from Marc:
Great book! I have some trouble with the ch 8.4. If you want say a service directly Map whith en table representation on the DB is en wrong thing I’am agree whith you. BUT, if a service is name âpersonâ and the result of get or put (a1b2c3) is a document of all the informationâs person, itâs SOA or old way? Personally I implement this on a large insurance company. This type of service in an entity service (for other author is a thin service) but I think for you is a coarse service. Coarse of course, because they are a lot of information. But itâs the more use and reuse service (itâs an attribute of thin service on another books). In fact we test deeply this architecture, and (because we make just 1 call) itâs more relevant than the RPC way (not for 1 call but itâs better after 2 call, ex. Person + adresses.
I think I am not use old way, whatâs your opinion?
PS sorry for my poor English, Iâm French !
Thanks for the compliment on the book :)
It doesn’t sound like what you’re doing is the “same old way” anti-pattern. The point of that anti-pattern is to say that that if you just put an SOA name on something which is essentially an n-tier architecture than it isn’t really SOA. Same goes for artificially inserting a “service layer” without taking the steps to separate and isolate services anywhere besides that layer.
In any event, when designing architectures, getting to a SOA or a RESTful or whatever is not a goal in itself. We can, and should, use design ideas from whatever paradigm and get something that is both a good fit for our problem and a sustainable solution for moving forward.
Hey, it's HighScalability time:
Don't miss all that the Internet has to say on Scalability, click below and become eventually consistent with all scalability knowledge...
Ever wonder what powers Google's world spirit sensing Zeitgeist service? No, it's not a homunculus of Georg Wilhelm Friedrich Hegel sitting in each browser. It's actually a stream processing (think streaming MapReduce on steroids) system called MillWheel, described in this very well written paper: MillWheel: Fault-Tolerant Stream Processing at Internet Scale. MillWheel isn't just used for Zeitgeist at Google, it's also used for streaming joins for a variety of Ads customers, generalized anomaly-detection service, and network switch and cluster health monitoring.
Abstract:MillWheel is a framework for building low-latency data-processing applications that is widely used at Google. Users specify a directed computation graph and application code for individual nodes, and the system manages persistent state and the continuous ïŹow of records, all within the envelope of the framework’s fault-tolerance guarantees.
This paper describes MillWheel’s programming model as well as its implementation. The case study of a continuous anomaly detector in use at Google serves to motivate how many of MillWheel’s features are used. MillWheel’s programming model provides a notion of logical time, making it simple to write time-based aggregations. MillWheel was designed from the outset with fault tolerance and scalability in mind. In practice, we ïŹnd that MillWheel’s unique combination of scalability, fault tolerance, and a versatile programming model lends itself to a wide variety of problems at Google.
This blog post will tell you exactly how to build a multi-terabyte high throughput datacenter server. A fast, reliable multi-terrabyte data tier can be used for recent behavior (messages, tweets, plays, actions), or anywhere that today you use Redis or Memcache.
You need to know:
Intel’s SATA solutions – combined with a high capacity storage server like the Dell R720xd and a host bus adapter based on the LSI 2208, and a Flash optimized database like Aerospike, enables high throughput and low latency.
In a wide configuration, with 12 to 20 drives per 2U server, individual servers can cost-effectively serve at high throughput with 16T at $2.50 per GB with the s3700, or $1.25 with the s3500. Other SSD offerings – from Crucial (Micron) and Samsung (S843) – are at other densities and price-performance points.
This is in-memory computing at a stunningly new, accessible price level – but there are some details you need to know...
The secret to 3-digit productivity growth is simple; stay focussed on your goal. One thing that keeps us from staying focussed is context switching; picking up a task, then interrupting it for another task and the starting up the previous task. Context switching originates from different levels within the organization. If you can effectively manage and decrease context switching, you can achieve amazing results and saveÂ a lot of resources. In this post I will tell you how to best combat context switching and gain more focus.
Last week we did sort of the same exercise with a group of six people at once, naming the sequences; a to z, 3 to 42 (in steps of three) and 5 to 60 (in fives). It was part of a presentation by Olav Maassen about context switching. He got really inspired by a talk at agile 2013 from Peter Saddington and decided to pass on some of the learnings to my colleagues and me.
Olav led the exercise and he would tell us when we needed to switch context. You can imagine the results. When Olav turned up the amount of switches, our team resulted in total chaos. Leading to a lot of laughs, but also many, many mistakes. In the last round, with the most context switches, we were six times slower to finish the exercise than without switching. That’s simply amazing; 600% better results with less context switches….
So if reducing context switching is a good thing, then letâs take a look at what practical things you can do to combat this phenomenon.
Context switching is a multilayered beast. “Why”, you ask? The answer is, because it is not only an issue originating on an individual level, but also on various other levels throughout the organization. In the section below, I will illustrate the individual, team, managerial and organizational levels and share measures you can take to combat context switching.
The individual level
People tend to pick up more work then they can handle at once. Of course there is a myriad of reasons as to why we like to do so, some positive and some negative.Â I believe people genuinely believe they will produce more by multitasking. Filling in the short periods of waiting time in between tasks, starting up activities and contributions by others so you do not have to wait for it later on etc.. From a negative perspective:Â to have the feeling we are busy and important, have the feeling we are worth our pay (the worst that could happen is idle timeâŠ), cover up for mistakes or to strengthen blame on others and avoid taking responsibility for seeing things through, solving issues and finishing work.
4 Things you can do to decrease context switching on an individual level:
The team level
On a team level there is context switching as well. Productowners can ask to work on various customer needs within the same team and sprint. This deludes the focus of the team by not having a clear goal. A thing I have seen many times is team(members) being asked informally to jump in and do some other important chore for managers, this chore even more important than the work at hand. Another common pitfall is that people expect the team to be able to handle improving and finishing work items at the same time.
7 things you can do to decrease context switching on team level are:
The managerial level
As usual it is the root of all evil that lies at the managerial levelâŠ. Well thatâs not exactly true, nevertheless there are a couple of things managers can do to reduce context switching.
3 things managers can do to counter context switching:
The organizational level
As we move on we get to the level regarding the orientation of teams. Now this is not so much a âthings you can do-sectionâ as it is a âwhat option best suits a non-context switching way of working â sectionâ. So lets get to it. There are roughly 4 ways to organize.
So if you are looking for things to combat context switching, you should change the team orientation to products. This also fits in best with the âbuild it, run itâ â principle from devops practices.
There are a lot of things you can do to combat context switching and gain more focus. Above all, context switching is a mindset change; accepting that it’s ok to be idle now and again if the upside is to have way better focus, providing and accepting feedback if you struggle with it and honoring focus even though your request is rejected because of this.
Context switching occurs on different levels within the organization. If you can effectively manage and decrease context switching, you can achieve great results. Imagine yourself being 600% faster. Sounds good? Implement the above suggestions and you will be well on your way to achieving amazing.
Like our ideas? Please check out our Xebia ACTÂ website to learn how Xebia can help you improve your time to market, reduce costs and improve quality using Agile and Lean best practices.